3 Nov
2006
3 Nov
'06
1:08 p.m.
On Fri, Nov 03, 2006 at 04:39:18PM +0000, Simon Jenkins wrote:
On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen
wrote:
There is no problem with this. They are handled in libjack which
will call one of the user's callbacks. This happens in the code block
named 'A' in my proposal, just as it does now.
The fact that we are inside jack_thread_wait() doesn't matter at all
- the callback is a function call like any other. The two forms are
really equivalent !
The event could arrive at an inconvenient time for the client,
but that is also the case in the normal structure. The worst
that could happen is that an algorithm has to be terminated
while it is still threaded. If that's the case you have to
code for it.
--
FA
Lascia la spina, cogli la rosa.
[...]
I'd say that the essential feature of JACK is not that it is a
callback based system, but that it presents and expects audio
data in fixed size blocks and enforces the rule that all clients
must have processed a block before the next arrives.
This could be done with blocking as well as with a callback,
and indeed it would be useful if JACK offered that option.
Fons, I remember your mail to jackit-devel on this subject:
http://sourceforge.net/mailarchive/message.php?msg_id=14073424
I had a question at the time which I didn't get around to asking which
is... What about event processing? (ie GraphReordered, BufferSizeChange
etc) These are delivered to the same thread in libjack that waits on the
buffers so they would be turning up somewhere inside your proposed
jack_thread_wait() function.