[LAU] multiJACK patch management: the first glimmerings

[Stéphane Letz]

> 
> Message: 11
> Date: Wed, 6 Apr 2016 00:26:32 +0200
> From: Alexandre DENIS <contact at alexandredenis.net>
> To: linux-audio-user at lists.linuxaudio.org
> Subject: Re: [LAU] multiJACK patch management: the first glimmerings
> 	of success
> Message-ID: <20160406002632.19d7ee47 at cocalight>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Tue, 5 Apr 2016 22:27:46 +0200
> J?rn Nettingsmeier <nettings at stackingdwarves.net> wrote:
> 
>> I have never used a graph as complex as Jonathan's, but I don't see
>> how adding virtual machine and networking overhead could improve
>> throughput when JACK2 should already parallelize everything that can
>> be parallelized... Wouldn't the time be better spent to analyze
>> JACK2's scheduling behaviour and catch bugs if there are any?
> 
> Hi,
> 
> Jack2 cannot parallelize processing if the graph is a pipeline: since
> every stage depends on the data from previous stage, they must be run
> in sequence.
> 
> However, a pipeline may be parallelized if you trade parallelism
> against latency. You can run each stage in parallel if they process
> data from different periods. Jack2 doesn't do that by itself since it
> would introduce uncontrolled latency.
> 
> When you run multiple jackd and link them with netjack, you introduce
> latency in the pipeline, which explains why you can have more
> parallelism. However, it looks completely overkill to me and
> introduces lots of overhead.
> 
> 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). Such a client should be no more than a few hundred lines of
> code.
> 
> -a.


jackd2 has a « loopback » driver implemented since day 1 (OK maybe day 2….)

- the code is in common/JackLoopbackDriver.cpp, h

- it can be activated using  the -L parameter like : jackd -L 4 -d also xxxxxx  to add 4 loopback ports.

Stéphane