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
Stephane
Received on Fri Nov 3 20:15:03 2006
This archive was generated by hypermail 2.1.8 : Fri Nov 03 2006 - 20:15:03 EET