[linux-audio-dev] jack_callback <-> rest of the world

fons adriaensen fons.adriaensen at skynet.be
Sun Oct 30 00:09:19 UTC 2005


On Sun, Oct 30, 2005 at 12:42:47AM +0200, Richard Spindler wrote:
 
> 1. what is the preferred way of feeding data from disk to the callback?

Use a separate thread to read ahead. Trigger it in the same way as 
you would for a thread that takes data from the callback.
 
> 2. What is the preferred way to notify the non-realtime thread that
> something happened in the jack-callback?
> A condition variable? How to avoid blocking? How do you do it?

In all my apps I use threads from (my own) libclthreads which is a
thin C++ abstaction of POSIX threads plus a communication system.
All these threads contain an object that encapsulates a set of 16
message queues implemented as linked lists, and 16 counting
semaphores, all 32 of them using a single condition variable plus
mutex. A thread can wait on any subset of these events and optionally
on a timeout.

To tell another thread that a callback has occured, I signal
(increment) one of the semas in the destination thread. There is
a very tiny chance that this could block, if the destination
happened to be in the (very short) critical section reading its
input events when it was pre-empted by jack's callback thread 
(I've never seen this happen).

If this is not acceptable, there is also a non-blocking version
of the sema operation. It fails when the normal one would block.
In that case the callback just remembers this and increments by
one more next time.

In more complex situations I would use a message containing
parameters for the other thread instead of the sema. Since
the message mechanism is zero-copy, there's virtually no
overhead compared to the sema, and it's anyway deliverd by
the same trigger.

On a 2.6 system you could also use futex based semaphores.
AFAIK, they never block on the V operation.


-- 
FA




 



More information about the Linux-audio-dev mailing list