hi all,
something im curious about and that i just cant believe:
Am Mittwoch, 22. Februar 2006 20:44 schrieb Frank Barknecht: [...snip...]
It's an ALSA specific thing, however it seems, that this was sorted out in the meantime [1], so you can ignore my message. (It had to do with the fact, that USB audio packets are generally transfered in blocks of a constant duration. Quoting Clemens Ladisch again:
"One USB frame is 1 ms, but the number of samples per USB frame varies if the sample rate isn't an integer multiple of 1000. E.g., at 44100 Hz, each USB frame has 44 samples, with one out of ten having 45." [2]
while it is sure that an usb frame is 1 msec (minimum, that is), i dont get it why "uneven" samplerates should cause a problem. first, you _never_ will have _exactly_ 44100 or 48000 for that matter. it has to do with the fact that crystals are always a little bit off. and since each soundcard has some crystal or oscillator somewhere, from which the actual samplerate is derieved, that samplerate would be almost never exactly be the given samplerate. its more like 44105 or 44093.
said that, same is true for each samplerate. the error gets lower if you use lower samplerates, but it will still exist.
_if_ soundcards, even of the same type and brand, _would_ have the exact samplerate, it would be super-easy to use multiple soundcards to get multichannel audio. but as we all know, that isnt possible easily.
if you have access to a frequency counter, you can check that yourself.
instead, to my understanding of the usb communication regarding sound, it is that the used "card" should handle that skew, even more, an intelligent device will request blocks as needed. that is, you have a constant blocksize of whatever you like, and while that block is processed, the next one arrives/is requested. so you can have fixed blocksizes for the usb frame, while just the timing is "skewed" a little to compensate, if at all.
also, 1 msec is the minimum time between each access to an endpoint (the device), but the device can stall the endpoint for a while when it has enough data left. that way, a device can use, for example, fixed blocks of 64 samples, "cache" a few blocks in advance, and only accept new data if there is a minimum amount left, so it would not get any underruns.
i may be that im wrong here with the above, but really, assuming that a samplerate of 44100 always gives you 44100 samples/seconds is plain wrong. same for any other samplerate. so in any case, an usb device has to handle samplerate variances anyway.....
on a different note about usb soundcards: there are single-chip "soundcards" like http://focus.ti.com/docs/prod/folders/print/pcm2702.html
if you read the datasheet, you will see that it has an "adaptive mode" to handle exactly the said problems .....
(and yes, only that chip and a few cheap other parts make a complete usb soundcard for at least audio out ;-)
greets,
chris