Re: [LAD] Some questions about the Jack callback

On Sat, 20 Sep 2014, Will Godfrey wrote: 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