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

[Anders Torger]

On Monday 24 February 2003 18.03, Martijn Sipkema wrote:
> [...]
>
> > > Perhaps you would reconsider having JACK use constant (frames)
> > > callbacks?
> >
> > I think a better solution might be to buffer up enough samples so
> > that jackd can provide a constant number of frames.
>
> I don't think that is a better solution. JACK should be close to the
> hardware and deliver what the hardware is capable of. If a client
> needs constant (frames) period, it can do the buffering itself.
>
> The buffering adds latency and complexity. I thought the idea of the
> callback based API was that the client has to process the data
> available when it is available. For some hardware this might be
> constant and for other it is not. As long as the time to process is
> roughly the same as the time the callback represents high cpu load
> should be possible.
>
> I'm not convinced that because of easier block processing in the
> clients support for common hardware should suffer.

Either you hide complexity in the API (that is JACK) or you give it to 
the applications. I think it is unwise to make it harder for the 
applications. There will be lots of reimplementation in all 
applications to handle the same set of problems you get when the period 
size can change. Any many will not care to implement to handle the 
special cases, and thus not work properly on all JACK compatible 
hardware.

Instead I would suggest a built in poll mode in JACK for audio hardware 
with strange period sizes. Although not the most beautiful solution, it 
will work reliably and will only be needed for the type of hardware 
that cannot provide interrupt rates which is a power of two.

/Anders Torger