On Tue, 9 Jan 2018 11:26:19 -0600 "Chris Caudle" <chris(a)chriscaudle.org> wrote: I seem to remember hearing somewhere that the jack server can't make use of multiple cores, but surely multiple *severs* could each be on their own core. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Tue, 9 Jan 2018, Will Godfrey wrote: Introducing a network layer adds more latency than creating a jack client with buffer that talks to two jackd servers. I believe jackd2 can use more than one core for non-dependant strings of clients. That is, a jack aware application could split two jack strings by calling itself two clients and buffering audio between them. However, the purpose of jackd is to provide known latency. Adding workarounds to make use of more cores destroys that. -- Len Ovens www.ovenwerks.net

On Tue, January 9, 2018 12:56 pm, Will Godfrey wrote: The jackd server is supposed to analyze the connection graph, and if it finds a string of connections with no dependencies on a separate string of connections, then it can put those two "strings" (for want of a better word) of connections on separate cores. The trick is having connection graphs without any dependencies. I don't know how common that is. I'm actually not sure what constitutes a dependent connection. For example, if you have a soft-synth generating audio and providing that on a jack port, and another soft-synth generating audio and providing that on a jack port, those two would have no dependencies. If the soft-synth MIDI inputs are then both connected to jack MIDI ports that are coming from the same a2jmidid connection, does that now make them dependent, and they can't be processed independently? So back up, assume the soft-synth instances are generating audio completely independently, e.g. they have their own internal sequencers, if the outputs are both connected to the same Ardour instance does that then make them dependent and force onto a single processor? If the answer to both of the above is yes then I do not know how you could have independent connection graphs in a realistic system. If the answer to either or both is no, that does not make the two soft-synth instances dependent in the connection graph, then maybe you could get the load to spread out across cores. -- Chris Caudle

On Tue, 2018-01-09 at 13:55 -0600, Chris Caudle wrote: I've got a lot to try. But I'm fairly certain I can do very well. Additional latency from localhost networking is going to be tiny beyond tiny, and unless I need yet more hardware, 4GHz should crunch Zita's numbers very nicely. I am currently thinking to run three soft servers thus: 1. Yoshimi 4x connected to non-mixer, and then triple Calf FX chain (Compressor, Reverb, EQ) 2. Calf-wrapped FluidSynth x7 or so connected to non-mixer, and then triple Calf FX chain (Compressor, Reverb, EQ) 3. Linuxsampler connected probably to single or double Calf FX (EQ at least) and then have all three streams to a hard server connected to the real hardware and doing nothing else. MIDI will be ALSA MIDI initially, I may eventually get brave and try one of the MIDI-over-IP methods. -- Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977 Hear us at http://ponderworthy.comcom -- CDs and MP3 now available! Music of compassion; fire, and life!!!

On Tue, January 9, 2018 5:31 pm, Jonathan E. Brickman wrote: Without knowing what the connection graph looks like it is difficult to say whether there is opportunity to spread the load across multiple cores. Having the DSP load so high compared to CPU load indicates that for the period length you have chosen there is a lot of overhead. The most reliable way to address that is to increase the period size. If using jackd 1.9.x evaluate whether there is some connection between ports that could be eliminated to make the connections available to be split across processors. I think htop should show you how many jackd threads are in use. Last resort (as an end user) would be tuning the software so that it runs more efficiently (e.g. making sure only true real time operations are done in the RT thread, and moving everything else to a separate thread). As a developer that should be first resort. -- Chris Caudle

On Tue, 2018-01-09 at 19:51 +0000, Fons Adriaensen wrote: Fons, many thanks, you unraveled the knot I was knotting tighter. I think I should have thought of that, multiCAST being the operative term :-) -- Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977 Hear us at http://ponderworthy.comcom -- CDs and MP3 now available! Music of compassion; fire, and life!!!