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

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

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user