Re: [LAU] multiJACK patch management: the first glimmerings of success

On 04/06/2016 12:36 AM, Will Godfrey wrote:
> On Tue, 5 Apr 2016 23:21:40 +0200
> Robin Gareus <robin@email-addr-hidden> 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Wed Apr 6 04:15:02 2016