On Fri, March 11, 2016 11:59 pm, Paul Davis wrote: > On Fri, Mar 11, 2016 at 7:17 AM, Patrick Shirkey > <pshir...@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)
Are we absolutely sure this is the case? That Jonathan has not found a "bug" in JACK2 or the DSP load algorithm? > - reduce the amount of work done by each client. According to Jonathan his multiple cores are barely reaching 5% usage. How can JACK_DSP be so high when there is so much room left to play with if JACK2 is handling the parallelism correctly? It seems similar to my car telling me that I am red lighting when I am only going 20km/hr in second. -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
