On 03/11/2016 05:53 PM, Jonathan Brickman wrote: >> > OK, I think I see what you are referring to: the switching nature of the > client list, where the JACK server has to switch between. And this is > entirely why it helps to run multiple JACK servers on multiple > motherboards, and why it will help to run multiple JACK servers on my > box, because the client list reduces tremendously per JACK server.
I'm curious how did you reach that conclusion? You either need to synchronize the multiple jacks or run them all independently each jack instance with its own soundcard. In either case the CPU will need to do at least as many context switches as running the whole thing in a single graph. In any case, the I don't believe the context switch overhead with only 19 clients is much of an issue here. First thing I'd check here is the scheduler: cyclictest -m -S -d0 -p80 is a good start. Leave it running for a while, the "Max:" at the end is relevant, those are usec. Ideally it'll not exceed 50 or so long term. If you want to dig deeper, compile jack2 with --profile it can print nice diagrams like http://www.grame.fr/ressources/publications/Timing.pdf including wake-up times for each of the clients; then again this is fairly advanced and the issue in your case is likely simpler. I didn't follow recent yoshimi development, but last I looked it was neither rt-safe nor very efficient. Some mutex/locks in the process callback could well explain why your CPUs idles a lot and jack does not work properly. Did you try recent zynaddsubfx? 2c, robin _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev