On 04/06/2016 12:36 AM, Will Godfrey wrote:
On Tue, 5 Apr 2016 23:21:40 +0200
Robin Gareus <robin(a)gareus.org> wrote:
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.
ciao,
robin
Hmmm. When was the last time you looked?
dunno, but I just re-checked.
JackEngine::processAudio() -> SynthEngine::MasterAudio ->
actionLock(lock) -> pthread_mutex_lock ()
I suggest
https://github.com/raboof/jack_interposer
```
cd /tmp/
git clone
https://github.com/raboof/jack_interposer.git
cd jack_interposer
make
LD_PRELOAD=/tmp/jack_interposer/jack_interposer.so yoshimi
```
I'm not aware of anything that can block the whole
of jack. Indeed, I've run a
fairly complex 12 part tune at 48k and only 16 frames/period on a poorly
optimised dual core machine, deliberately getting it to produce the occasional
Xrun to see how it recovered. It typically produces 2 inaudible ones during the
5 minute track. As far as I'm aware nothing was being blocked. It simply ran out
of time under these (frankly insane) conditions.
As long as yoshimi is the only midi client there is no lock contention.
However the jack graph that Jonathan is running has multiple stages
depending on each other including multiple instances of yoshimi. I can
well imagine that blocking one thread can have significant effects.
best,
robin