24 Feb
2003
24 Feb
'03
1:33 p.m.
On Monday 24 February 2003 18.03, Martijn Sipkema wrote:
[...]
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
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.