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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Mar 12 04:15:02 2016
This archive was generated by hypermail 2.1.8 : Sat Mar 12 2016 - 04:15:02 EET