Re: [LAD] Some questions about the Jack callback

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
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev