[PD-ot] ./configure

[Christian Klippel]

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