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