[LAD] Multiple JACK servers connected in one host?

[Patrick Shirkey]

On Fri, March 11, 2016 2:13 pm, Paul Davis wrote:
> 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.
>

If this was a hardware issue where one physical module had becoming a
bottleneck the obvious solution is to add additional modules to expand the
pipeline.

What is the specific problem with having multiple JACK instances running
on the same desktop. Why can't a modern parallel CPU with 8 hyperthreads
run multiple instances of JACK? It also offers some interesting potential
for session management.

If a user has a 64 core desktop it would be absurd if we cannot enable
s/he to use it to the full potential because one instance of JACK is
getting overloaded when the vast majority of processing cores are not even
being used.

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.




>
> On Thu, Mar 10, 2016 at 9:28 PM, Jonathan E. Brickman
> <jeb at 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 at 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 at lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>>
>>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>


--
Patrick Shirkey
Boost Hardware Ltd