24 Feb
2003
24 Feb
'03
1:11 p.m.
[...]
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.
--ms
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.