[linux-audio-dev] OSS will be back

[Simon Jenkins]

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






> Stephane