11 Mar
2016
11 Mar
'16
1:59 p.m.
On Fri, Mar 11, 2016 at 7:17 AM, Patrick Shirkey <pshirkey(a)boosthardware.com
wrote:
On Fri, March 11, 2016 6:58 pm, Robin Gareus wrote:
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.
On 03/11/2016 08:03 AM, Patrick Shirkey wrote:
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.
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?
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.