[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