3 Nov
2006
3 Nov
'06
1:21 p.m.
Le 3 nov. 06 à 18:16, Simon Jenkins a écrit :
On Fri, 2006-11-03 at 17:50 +0100, Stéphane Letz
wrote:
jackdmp is c) already.
Stephane
Le 3 nov. 06 à 17:39, Simon Jenkins a écrit :
Possible, but a lot more effort in current JACK and no good reason
(that
I can see at the moment) to do it that way.
How about jackdmp? Which of a) b) or c) would be easier or better
there?
Simon
On Fri, 2006-11-03 at 08:53 +0100, Fons
Adriaensen wrote:
c) or move to a 2 threads model: one for RT audio, one for
notification event handling [...]
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.
Two possible approaches would be:
a) Stick with callbacks for events
b) Poll for events
In either case when you called jack_thread_wait() it would wait for
events and/or a buffer. The difference is that in a) it would call a
callback whenever it got an event but only return to caller when it
got
a buffer, whereas in b) it would return to caller on either an
event or
a buffer with an indication of which had arrived.
a) would be easiest and I can't see any advantage in b). What do you
think?
Simon
Stephane