[LAU] multiJACK patch management: the first glimmerings of success

Robin Gareus robin at gareus.org
Wed Apr 6 23:57:07 UTC 2016

On 04/06/2016 11:27 PM, Fons Adriaensen wrote:
> On Wed, Apr 06, 2016 at 12:26:32AM +0200, Alexandre DENIS wrote:
>> I think it should be doable to write a simple client that connects as
>> two unrelated clients to jack, and feeds its outputs with its inputs
>> with one period of delay. It will make jack2 run the client connected
>> to its inputs and to its outputs in parallel, since jackd doesn't see
>> it as a dependency; but the latency of one period is unavoidable, since
>> we cannot predict whether jackd will invoke first the callback for the
>> inputs or for the output (or maybe at the same time on different
>> cores).
> The latency is indeed unavoidable, but not for the reason
> you mention. The order of execution of the two parts of
> the 'delay' client must not be random.
> You need to ensure that the 'in' client runs after the 'out'
> client. This can be done easily by having a dummy connection.
> In other words, you'd have something like
>    X -> [ A <- B ] -> Y 
> Then in each cycle X and B can run immediately. B copies
> the data input by A in the previous cycle to its outputs 
> (this can be very fast), then Y runs while X can still
> be busy. When X terminates, A stores the data to be read
> by B in the next cycle.
> In case X terminates before B, A still has to wait for
> B to terminate - this ensures that Y always has the
> one cycle delayed output from X.

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.


More information about the Linux-audio-user mailing list