[LAD] Some questions about the Jack callback

Len Ovens len at ovenwerks.net
Sat Sep 20 17:07:11 UTC 2014

On Sat, 20 Sep 2014, Will Godfrey wrote:

> While getting to grips with Yoshimi I set up a microsecond timer in the function
> that actually generates the data. To get a worst-case scenario I did this on my
> office machine that's not specially set up for audio.
> I configured jack for 512 frames/period, 2 periods/buffer and 48k, giving an
> overall latency of 21.3mS
> Running a moderately complex 12 part tune, the data 'build' time was varying
> between about 1.8mS and 6.1mS per buffer. It dropped to less than 1mS when there
> was no sound being produced.

Is it possible to deal with this in two threads? In the case of generating 
audio, there is no "waiting" for audio to come in to process and the 
processing could start for the next cycle right after the callback rather 
than waiting for the next callback(thinking multicore processors). The 
outgoing audio is put into storage and the callback only puts it into the 
audio stream. Effectively, the generation thread would be running in sort 
of a freerun mode, filling up a buffer as there is room to do so. The RT 
thread would just transfer audio from the buffer to jack. I have 
simplified things a lot... and am basing this on my small experience with 
taking data from a socket as it arives, processing it into midi events, 
dropping it into a buffer. The RT callback checks the buffer for valid 
MIDI events and if found sends them. For me a midi event is stored as one 
byte size_of_event followed by size_bytes data. The data is stored first 
while the size = 0 and the size is set last after the data has been 
written. The callback looks for a size > 0 to check for valid data, sends 
it and sets size back to 0.

In my case, event collection is slow (there will not be events for each 
buffer in general) compared to what you are doing, so I don't know if the 
same thing would work for you.

Even on a single core system, your process could be using spare time after 
jack has gone through it's graph to get started on the next period. (no I 
am not sure that would make any difference :)

Len Ovens

More information about the Linux-audio-dev mailing list