<div dir="ltr"><div><div>so, you've got 6 non-parallelizable stages. the first stage (3 instances of yoshimi, plus stringbassacid plus stringsSSO) has 5 clients that can be in parallel. The second stage (Mixer/*) has 6 clients that can be run in parallel. The third stage has 3 clients (Mixer/* and 1 yoshimi) that can be run in parallel. the 4th stage has 3 clients that be run in parallel. the 5th stage has 1 client, as does the 6th.<br><br></div>basically, this is a picture perfect demonstration to me of why the process-level parallelism that JACK enables is just a bad idea. Distributing this amount of processing across 19 JACK clients some of which are parallelizable and some are not is, to my mind (as JACK's original author) precisely how the program should never be used.<br><br></div>maybe someone will find a way for you to do what you want, but I personally think that this whole workflow is ill-conceived. i'm sorry that JACK's capabilities led you to this, because I think you're not well served with this tool configuration.<br><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 9:28 PM, Jonathan E. Brickman <span dir="ltr"><<a href="mailto:jeb@ponderworthy.com" target="_blank">jeb@ponderworthy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote type="cite">
<blockquote type="cite"><span class="">
<blockquote type="cite">
<pre>What is happening right now, is I have seven synth+filter chains, all
run through the single JACK server, all feeding eventually into the one
sound card. I have more than ample CPU to run them all, but as you and
others have explained, one JACK server is reaching its limits to handle
them all because of the limits of the synchronous nature of everything.
So what I intend to do, is to run all of the chains independently,
asynchronously, on their own JACK servers, and then combine them all
into a separate final which will connect to the sound card. This is
being done already with as many motherboards as desired, but I would
like to do it within one very powerful box.
</pre>
</blockquote>
</span><pre>Maybe some visualisation of your jack graph could help, I think patchage
can export the structure of that into a dot/graphviz file, you could
attach that. Information about the strain each of these filters puts on
the CPU would be helpful as a hint too. That would not be the number at
the top of htop, but next to the process of each of these filters.</pre>
</blockquote>
</blockquote>
The DOT is attached. At max load, the only CPU being stressed more
than 5% is running just one of the Yoshimi processes, one taking
high ranges in patch SRO; this one CPU is kept at a steady 14% when
SRO is sounding with maximum notes. There is no very significant
CPU stress, just maxing-out of JACK DSP.<span class=""><br>
<br>
<div>-- <br>
<div style="color:#993300;font-size:0.8em;font-style:italic">
Jonathan E. Brickman <a href="mailto:jeb@ponderworthy.com" target="_blank">jeb@ponderworthy.com</a> <a href="tel:%28785%29233-9977" value="+17852339977" target="_blank">(785)233-9977</a><br>
Hear us at <a href="http://ponderworthy.com" target="_blank">http://ponderworthy.com</a>
-- CDs and MP3 <a href="http://ponderworthy.com/ad-astra/ad-astra.html" target="_blank">now
available!</a><br>
Music of compassion; fire, and life!!!
</div>
</div>
</span></div>
<br>_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" rel="noreferrer" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
<br></blockquote></div><br></div></div></div></div>