On 04/05/2016 10:27 PM, Jörn Nettingsmeier wrote: > In any case, I'd say it would be useful to come up with at least a > working hypothesis of why this should improve things. yes, please. I'd love to hear one myself. Best guess so far is Yoshimi. Last I looked the jack-client still had locks for synchronizing audio+midi i/o and can block all of jack. Multiple instances of jackd could mitigate this. I'd still like to know if the same setup with zynaddsubfx (instead of yoshimi) has the same issue. zyn is known to be rt-safe. > I have never used a graph as complex as Jonathan's Actually, I've seen some Ardour sessions on your machine which have a much more complicated graph. That TIH ambisonics session with 2 tetraprocs external zita-rev and jconvolvers for example exercises both Ardour's internal graph as well as jack2's external graph. > When exporting, I have seen something that might be similar to what > Jonathan might be seeing: a freewheeling, 100% CPU-bound process only > seems to use a fraction of the available CPU even on a single core. Now > this might indicate a real problem, or it might indicate that the CPU > load tools I'm using do not accurately report what's going on under > tight real-time conditions with loads of context switches. Ardour export? if so that does not use jack's parallel graph at all. Ardour is a single jack client. The most likely the bottleneck here is disk-i/o (reading audio from all tracks, writing the exported audio). ciao, robin _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
