Subject: Re: [linux-audio-dev] BruteFIR + jack = crackling noise?
From: Anders Torger (torger_AT_ludd.luth.se)
Date: Mon Feb 24 2003 - 19:25:23 EET
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
This archive was generated by hypermail 2b28 : Mon Feb 24 2003 - 19:26:29 EET