On Wed, 6 Apr 2016 01:53:37 +0200 Robin Gareus <robin@xxxxxxxxxx> wrote: > On 04/06/2016 12:36 AM, Will Godfrey wrote: > > On Tue, 5 Apr 2016 23:21:40 +0200 > > Robin Gareus <robin@xxxxxxxxxx> 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 Interesting. I'll follow this up. ... after next week :) -- 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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
