[linux-audio-dev] OSS will be back

Fons Adriaensen fons.adriaensen at skynet.be
Fri Nov 3 17:10:57 UTC 2006


On Fri, Nov 03, 2006 at 04:39:18PM +0000, Simon Jenkins wrote:
> 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.

There is no problem with this. They are handled in libjack which
will call one of the user's callbacks. This happens in the code block
named 'A' in my proposal, just as it does now.

The fact that we are inside jack_thread_wait() doesn't matter at all
- the callback is a function call like any other. The two forms are
really equivalent !

The event could arrive at an inconvenient time for the client,
but that is also the case in the normal structure. The worst
that could happen is that an algorithm has to be terminated
while it is still threaded. If that's the case you have to
code for it.  

-- 
FA

Lascia la spina, cogli la rosa.




More information about the Linux-audio-dev mailing list