On Tue, 5 Apr 2016 22:27:46 +0200 Jörn Nettingsmeier <nettings@xxxxxxxxxxxxxxxxxxx> 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.
Attachment:
pgpGko7ye3p7k.pgp
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
