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

Martijn Sipkema msipkema at sipkema-digital.com
Tue Feb 25 15:02:01 UTC 2003


> >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.

Well, I disagree. I don't think it is a stupid design.

> >> 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.

To say it another way: JACK only supports one 'interrupt' source. This
can apparently be several devices made to look like one by ALSA, but
this does not change the fact that JACK itself only supports one driver.

> >> 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.

That is correct. Indeed some devices allow varispeed. This means that
you'll have to have a processing reserve for high speed. Having interrupts
at constant time or frames doesn't really matter. You are correct in that
well designed hardware will provide interrupts at regular intervals.

> 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.

I'm not advocating USB audio. (I'd rather see Firewire being used for
audio more.) And you are correct in saying that the variation in frames
per callback needs to be small. But there are audio interfaces that
do exactly that: they provide nearly constant frames per callback.
And I don't see any reason why JACK should not properly support
such hardware.

> 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.

And thus JACK will not support USB audio devices properly? And
perhaps other hardware that is 'broken'? I think this is a mistake.

And also, I think it would be good algorithm design to make it
independent of the number of frames per callback/process.

--ms






More information about the Linux-audio-dev mailing list