[linux-audio-dev] OSS will be back

Stéphane Letz letz at grame.fr
Fri Nov 3 16:50:02 UTC 2006

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


More information about the Linux-audio-dev mailing list