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

Fons Adriaensen fons at linuxaudio.org
Wed Apr 6 21:27:35 UTC 2016

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.



A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

More information about the Linux-audio-user mailing list