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 > <j...@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 j...@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@lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-dev >> >> > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
