[time-nuts] Using cheap sound cards for measurements

[Hal Murray]

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.