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
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
