[LAU] multiJACK patch management: the first glimmerings of success
Will Godfrey
willgodfrey at musically.me.uk
Wed Apr 6 00:10:26 UTC 2016
On Wed, 6 Apr 2016 01:53:37 +0200
Robin Gareus <robin at gareus.org> wrote:
> On 04/06/2016 12:36 AM, Will Godfrey wrote:
> > On Tue, 5 Apr 2016 23:21:40 +0200
> > Robin Gareus <robin at 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
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.
More information about the Linux-audio-user
mailing list