11 Mar
2016
11 Mar
'16
4:13 a.m.
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(a)ponderworthy.com>
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(a)ponderworthy.com (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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev