[linux-audio-dev] BruteFIR + jack = crackling noise?

[Paul Davis]

>IMHO the hardware should dictate the blocksize. For most audio
>interfaces this will be constant. For some it is not.

the claim is that designs in which it is not constant are at least
less than optimal and at worst, just stupid.

>> Anyway, if you have several HW interfaces
>> each using their own blocksize or interrupt frequency then this is the
>> only sane option.
>
>This is another issue. JACK doesn't not support more than one device
>nor should it. If an application wants to use more than one device the
>extra buffering and possibly synchronisation is up the the application.

actually, this is not the model at all. the model is that JACK doesn't
interact with hardware, but with more abstract devices, such as those
represented by ALSA PCM devices. if such a device maps to multiple
audio interfaces, JACK doesn't care, but its up to alsa-lib to make
this work, not JACK and not JACK clients. 

the same is true of any other app using the ALSA API: you do not need
any extra code to deal with the specifics of what kind of "thing" an
ALSA PCM device is: it could be a connection to a JACK server, to a
network connection, to just the s/pdif ports of a multichannel
interface, to 4 cards ganged together and clocked via word clock. the
app just doesn't have to care.

>> If this means an extra buffering layer, then so be it. That's the
>> price you pay for sloppy HW design.
>
>I really don't think that hardware that doesn't provide a constant
>number of samples per interrupt is sloppy HW design and I think

the number of samples per second is constant (except for when changing
rates or doing something truly wierd like word-clock driven
varispeed). to keep CPU load even, one wants a constant number of
interrupts per second. ergo, the number of samples per interrupt
should be constant.

look, the point is just this: USB was never designed to handle audio,
let alone multichannel audio. its been stitched together, patched up
and made to work, but it doesn't work very well. the CPU wants to
process samples in chunks of the same size to equalize the load,
otherwise you have a situation that is impossible to rely on (e.g. you
are running close the CPU's available cycles at a given
blocksize. suddenly you get a run of "small" blocks. boom!) now,
obviously, if the variation is small (e.g. 1-4 samples) it may not
matter so much, but its not clear that a design that allows variations
of 1-4 samples can exclude the 1024-4096 case either.

yes, you can move audio over USB. the question is not whether you can,
but whether you should, and my feeling is that professional or
semi-professional users should avoid it completely, regardless of what
Yamaha, Tascam, Edirol and others who want to provide *cheap*
connectivity to home studio users say in the advertisements.

--p