[LAU] Linux audio app design: The nature of xruns

[Ken Restivo]

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 at gmx.de> a ??crit :
> 
> > 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.
> 

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