Re: [LAU] multiJACK patch management: the first glimmerings

Message: 11 Date: Wed, 6 Apr 2016 00:26:32 +0200 From: Alexandre DENIS &lt;contact(a)alexandredenis.net&gt; To: linux-audio-user(a)lists.linuxaudio.org Subject: Re: [LAU] multiJACK patch management: the first glimmerings of success Message-ID: <20160406002632.19d7ee47@cocalight> Content-Type: text/plain; charset="iso-8859-1" On Tue, 5 Apr 2016 22:27:46 +0200 J?rn Nettingsmeier &lt;nettings(a)stackingdwarves.net&gt; wrote: 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.