3 Jan
2010
3 Jan
'10
3:20 p.m.
On Mon, Dec 28, 2009 at 02:19:35PM -0500, lanas wrote:
Le Lundi, 28 D??cembre 2009 16:00:04 +0100,
Dominic Sacr?? <dominic.sacre(a)gmx.de> a ??crit :
The general approach I've seen in well-behaved apps is to do all the audio processing
in a separate thread, and stream the resulting 32-bit floats into a shared circular
buffer. The JACK callback then does little if anything more than just reading floats out
of the buffer, and incrementing a counter or pointer (not protected by any mutex, the JACK
callback thread is the only thing that writes it, and all other threads only read it) to
show where it left off. Keeps the jack callback thread very light.
Then again, this is my completely novice impression from only reading the code of various
JACK apps, never actually writing one myself.
-ken
The rules are quite simple, but in many cases not
exactly easy to
implement.
Inside the JACK process callback, you may not
call anything that
might block, i.e. that might suspend the calling thread indefinitely.
That includes:
- memory allocations (and deallocations)
- waiting for mutexes etc.
- file IO, printing to the console, etc.
Thanks for the pointers. For me this does not consitute any problem.
Such callbacks must be treated like, if I may make the analogy, the
bottom part of an ISR.
The main difficulty lies in the fact that these
things are often
hidden deep inside some library code. So you should either verify
that a function is safe to use in realtime code, or avoid using it in
this context.
Yes. It is better to set context and return from such callbacks
as soon as possible. Then some kind of observer, free of such time
contraints, would react on the set context variables/structures.
As for common solutions to these problems, the
link to the previous
thread David posted should be a good start.
Thanks to David also. I'll start reading the JACK API. Looks
interesting from a programming point of view.