[linux-audio-dev] OSS will be back
letz at grame.fr
Fri Nov 3 17:19:09 UTC 2006
Le 3 nov. 06 à 18:16, Simon Jenkins a écrit :
> 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:
>>> I had a question at the time which I didn't get around to asking
>>> is... What about event processing? (ie GraphReordered,
>>> 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
>>> 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
>> 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
> 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
jackdmp is c) already.
More information about the Linux-audio-dev