[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.

2c,
robin


More information about the Linux-audio-user mailing list