[LAU] multiJACK patch management: the first glimmerings of success
markus.seeber at spectralbird.de
Thu Apr 7 14:53:17 UTC 2016
On 04/07/2016 01:57 AM, Robin Gareus wrote:
> How would that effectively differ from running at twice the buffersize?
> That approach just moves the load to two CPU cores. If those two cores
> can produce the result in a given time, a single core can do the same
> with twice the buffersize. Identical total latency.
This is called interleaved scheduling and gives a scheduler the option
to run tasks in parallel by interleaving two (or more) process cycles.
This differs from using a double buffer size because the scheduler has
more opportunity to fill "holes" in the schedule, that are introduces by
client dependencies in the graph.
Doing this by hand (as described by bridiging multiple jack instances)
moves the responsibility of interleaving the two jack schedules to the
kernel scheduler and may theoretically bring better resource usage in
some special cases, but also has some pitfalls.
The right way to to this, would be to implement this in the sound
server, but if this makes sense for the use cases of jack2 is a
different question. Also it increases the risk of getting xruns from
clients with non constant runtime in their process callback.
More information about the Linux-audio-user