[chuck-dev] Big Nasty Mutex (tm) + Jack + ChucK evilness

[Ge Wang]

I must confess.  I don't know Jack.

So...

Before we, heh, re-implement ChucK and RtAudio, I would like to
know the following, at least:

1. Why is the mutex actually bad?  More specifically, how exactly
does it cause Jack to fail or zombie?  ChucK does not call RtAudio
from multiple threads, so the mutex shouldn't be blocking at all.

2. If the concern is things taking too long in the callback, how does
putting audio synthesis in the callback help?  The current scheme
has the audio pre-computed before the callback.  Putting the most
time consuming part of ChucK inside the callback will more likely
delay the callback.

Dave, you said that replacing blocking I/O with computing audio in
callback makes things robust, regardless of load.   How does Jack
know the difference between the callback blocking versus just taking
a long time computing audio?  I am clearly missing something here.

Related question:

3.  Under what conditions does Jack decide to boot a process?

4. If our blocking scheme is the problem, then why doesn't sndpeek
work?  The callback just copies the input buffer and returns.

Confused,
Ge!