On Fri, Mar 11, 2016 at 7:17 AM, Patrick Shirkey <pshirkey@boosthardware.com> wrote:

On Fri, March 11, 2016 6:58 pm, Robin Gareus wrote:
> On 03/11/2016 08:03 AM, Patrick Shirkey wrote:
>> If this cannot be fixed in JACK directly we should be able to spin up
>> multiple instances on the same machine and have them play nice with each
>> other.
>
> and how would that be different from splitting the current graph in JACK
> and not preform worse?

Currently it seems that we cant do either so which method is preferable?

According to Jonathan's results he is finding a bottle neck with JACK DSP
with a single server. In the absense of a fix for JACK so that it is not a
bottle neck his solution is to run multiple servers on the same machine.
However it seems that it is not possible to have more than 2 instances of
JACK running on the same machine without using a virtual
machine/environment.

According to Paul the issue is that we should not rely on JACK to create a
processing graph like Jonathans.

Not quite what I said, but close enough.

20 context switches minimum per process() cycle. This isn't dramatic, but it is notable. Some of them might not be context switches if the "Mixer" stuff is actually an example of a multi-client process - I don't know.

I don't see much difference between a single server with multiple graphs
or multiple servers

That isn't the choice. The choice is threeway:

- reduce overhead caused by context switching between programs

- reduce DSP load by running more in parallel (this is dependent on the graph; JACK2 will do

the best possible already, so if Jonathan is already using JACK2, maximum parallelism

is already in use)

- reduce the amount of work done by each client.