[time-nuts] Using cheap sound cards for measurements

Demian Martin demianm_1 at yahoo.com
Tue Aug 25 00:13:04 UTC 2009


Here is a backgrounder on the 44.1 KHz sample frequency. I dimly remembered
that it was related to video.
http://www.cs.columbia.edu/~hgs/audio/44.1.html

USB audio is often outside the AES spec for frequency since the USB clock
isn't easily related to 44.1 or 48. Some external DAC's won't lock to USB
spdif sources since they are so far out. The clock is derived from the PC's
internal clocks. USB audio output is usually locked and syncronous to the
PC's USB interface so a local clock would require buffering and some way to
manage the data. There is an asyncronous audio for USB standard but not used
except by a few devices. A lot of the pro market uses Firewire for this
reason and others. 

The spec for a good digital audio chip is here:
http://envy24.svobodno.com/datasheets/via/vt1724.pdf and a lot more here:
http://envy24.svobodno.com/datasheets/


Demian Martin
PDS

From: Hal Murray <hmurray at megapathdsl.net>
Subject: Re: [time-nuts] Using cheap sound cards for measurements

james.p.lux at jpl.nasa.gov said:
[External clock at strange frequency.]

> That's an interesting idea.  I would imagine that the clock going into
> the chip is probably some multiple of the sample rate (e.g. 48kHz*16*2
> = 1.536 MHz), so you could pick the closest 1/N from 10 MHz and pump
> that in.

> However, what about the USB interface?  These are inexpensive devices,
> and I'll bet all the rates are carefully chosen so that everything
> shares one clock. 

I guess somebody will have to take the lid off and look inside.

Most USB gizmos that I've looked at have something like a 24 MHz crystal.  I

assume that is a sweet spot for cost.  At the root hub, that turns into the 
clock/bit rate.  At the device end, I think it's PLLed to the upstream
clock.

My guess is that any claimed-to-be-good audio gear would have it's own audio

clock just to avoid the wander as the PLL follows its view of the upstream 
clock.

I don't understand the audio numbers.  Is there a crystal frequency that 
works well with all normal sampling frequencies?  I don't see one if you
want 
both 44.1 and 48 KHz.  (There could easily be some sneaky scheme I don't
know 
about.)




tractorb at ihug.co.nz said:
> Are USB data transfer delay times an issue?  IIRC they can vary quite
> a lot, depending on processor loading etc. DaveB, NZ 

USB gets a lot of bad press because it's polled.  In reality, that polling
is 
implemented in hardware so there is another layer of buffering to separate 
things from the interrupt latency.

One big question for communication systems is how much buffering do you
need? 
 Buffers are expensive (or were in the old days) so hardware guys try to 
avoid them.  On the other hand, they let software guys be sloppy so software

guys always want more buffering.

USB has two modes sharing the same controller and tree of wires.  Devices 
like audio gear can reserve bandwidth.  All the rest of the bandwidth is 
shared by the other devices like disks.

So something like an audio device would get allocated X bytes per polling 
interval and hence needs enough buffering for that much data.  X is just the

data rate times the polling interval.  (rounding up a bit)

I think the USB 1.1 polling interval is 1 ms.  I think the USB 2.0 polling 
interval has stuff to get lower than 1 ms while still working with the old 
1.1 stuff.  I'd have to do some work to understand the details.

The bottom line is that USB was designed with things like audio in mind so
it 
should do a good job.  That's assuming reasonable driver support and OS 
support and good applications and probably several other factors too.

Modern OSes have support for real-time work.  You should be able to write 
code that reads from USB, crunches the data, and writes a summary to disk, 
and does that while the system is also doing other work.  That's assuming 
that you only need reasonable amounts of CPU, memory, disk, whatever...  
Mostly, this allocates some CPU to that work, giving the rest of the CPU to 
the non real-time work.  (Roughly like USB bandwidth is allocated.)




-- 
These are my opinions, not necessarily my employer's.  I hate spam.
> *****************************************




More information about the time-nuts mailing list