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

[Alexandre DENIS]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20160406/e2dac34f/attachment.pgp>