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.
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.
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.
On Thu, Mar 10, 2016 at 9:28 PM, Jonathan E. Brickman <jeb@email-addr-hidden>
wrote:
>
> 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.
>
> 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.
>
> 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.
>
> --
> Jonathan E. Brickman jeb@email-addr-hidden (785)233-9977
> Hear us at http://ponderworthy.com -- CDs and MP3 now available!
> <http://ponderworthy.com/ad-astra/ad-astra.html>
> Music of compassion; fire, and life!!!
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Mar 11 08:15:02 2016
This archive was generated by hypermail 2.1.8 : Fri Mar 11 2016 - 08:15:02 EET