[PlanetCCRMA] Re: Mulitple Jack audio interfaces (was Tascam US-122 audio problem)

Andrew Burgess aab@cichlid.com
Sat Feb 26 15:11:01 2005


>> >>but with unmodified consumer PCI devices you have no
>> >>source of sync, the drift will be substantially more than 1 sample every
>> >>100k.
>> 
>> >How much more substantial will it be? That seems like a high guess to me,
>> >aren't crystals accurate to a few ppm?

>100-200ppm at the outset for inexpensive crystals, independent of
>temperature drift and changes over lifetime.

>> I ran some overnight tests and found with 3 soundcards (2 usb and one mb)
>> the rates differed by 2-4 samples/sec. About 10 times more than my 100k
>> estimate (oops).

4/48000 is 83ppm for my three card test case.
This was using gettimeofday(2) and non-realtime priorities.

>These crystals will change frequency slightly
>over the day. They speed up and slow down.
..

Yes I know, that's why you must adjust dynamically.

>The only thing I think you can do in this space is to count samples.

Yes

>If you know that all devices generate 44100 samples in whatever period
>of time they consider a second to be then you could arbitrarily
>designate one of them to be the master '44100 sample supplier' and
>then *possibly* do some adjustment to your other sample streams based
>on that. 

I don't think of one being the master. I think you have a source and
a destination for your samples and if the sample rates differ (thus they
represent two different soundcards) then you adjust.

>What that adjustment is would be complex as you would
>sometimes be adding and sometimes subtracting samples.

What's complex? If you have a good number for the actual sample rate
you just do the arithmetic, no? Getting the actual sample rate
seems the biggest challenge now. I still haven't looked at the timestamps
available from alsa.

>It seems to me that this would invariably lead to clicks and pops, and
>that should you choose to do it every second then you'll end up with
>some repetitive click that's likely to be more noticeable.

Not every second, every N samples where N is the computed rate difference.
So for a while (or once) it might be a insert a sample every 10,123 samples
then for a while discard one after every 8,456 samples.

>> I think I'll try generating some pure sin tones and see if I can
>> audibly detect sample insertion/deletion, or maybe try to find the
>> detection threshold.

This is the test I still have to run to determine if the corrections will
be audible. I imagine if you can't hear it with a pure tone you won't hear it
with complex material.

I do appreciate your interest.