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

[Arnold Krille]

Hi,

On Sunday 03 January 2010 20:19:10 Ken Restivo wrote:
> 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.

But the main reason for the jack-thread is that processing there happens when 
jack needs it and with the priority jacks needs while all the extra threads 
(gui is one of them) have lower priority to not block the audio stuff. When you 
do the audio creation in another thread and only push it to the jack-threads 
ringbuffer, you have to make sure that buffer is always filled to not get gaps 
(actual xruns but without jack complaining, only audio missing).
While this works when you "just" stream media from disk, this will not work 
with samplers/synths/effects as these react to external signals that come in in 
the same priority and should be processed as fast as possible instead of when 
the to-jack-ringbuffer actually reaches that data...

If the sampler uses a separate thread (with lower priority), this would mean 
that the midi-event comes in and the according tone is just generated and 
appended to the ringbuffer. Some time in the future the ringbuffer would get 
sent to jack. But you actually want the jack-thread to only interpolate the 
events time inside its current audio-buffer and push the tone out as fast as 
possible. Otherwise there would be no valid reason to tune the audio-latency 
to low values for live-synths and effects...

A well behaved jack app is not one that does almost nothing inside the jack-
callback, its one that does what is necessary as fast as possible. That 
implies not using certain operations such as new/delete/free/malloc but allows 
for audio generation to be done inside the callback.
And especially this allows for the callback to process the incoming audio and 
output it again in the very same call. (Which makes JackMix well-behaved:) 
Otherwise mixing and effects would all add a delay you don't want.

Have fun,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20100103/e76d2206/attachment.pgp