[linux-audio-dev] OSS will be back

[Stéphane Letz]

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:
>>>
>>> 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
>

jackdmp is c) already.

Stephane

>
>
>
>
>
>> Stephane
>
>