On Fri, 2006-11-03 at 17:50 +0100, Stéphane Letz wrote: > Le 3 nov. 06 à 17:39, Simon Jenkins a écrit : > > > On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote: > >> [...] > >> 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 > > > > c) or move to a 2 threads model: one for RT audio, one for > notification event handling
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 > Stephane