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

[Dave Robillard]

On Sun, 2005-13-03 at 09:43 -0500, Gary P.Scavone wrote:
> Hi Everyone,
> 
> I hope to have some time later this week to look at the RtAudio Jack 
> code, though it appears that the main problems lie elsewhere in the 
> ChucK code.  With respect to the "big fat mutex", it is there to 
> protect _all_ the RtAudio functions from the user making multiple calls 
> simultaneously (perhaps on a multi-processor system) that might 
> interfere with each other.  In the long run, it might be unnecessary 
> and perhaps we can make do without it, but I chose to be "safer" than 
> "sorrier".

I'd say it's pretty reasonable to require clients to not do thing like
that.  The mutex really should go, anyway.  Maybe some functions need to
be changed to be okay to execute in parallel without locking?

> I'll add "my two cents" with regard to the scheduling:  The Jack 
> community espouses the callback paradigm as the only solution to 
> realtime audio i/o ... I've been hearing this loudly for the last 4-5 
> years.  Then there's a bunch of us that used to do things with blocking 
> calls and know how easy it was to make them work with the same 
> consistency as the callback paradigm.  This last sentence will raise 
> arguments like "there is no way that a blocking paradigm can be as 
> robust as a callback paradigm".  I'm not here to convince ... I simply 
> know from experience.  In fact, I find it much easier to work with 
> blocking functions and embed them in threads to "simulate" a callback 
> scheme ... the reverse is nearly impossible.

Hmm.  I would say the exact opposite actually.  Wrapping a callback
function in a blocking IO system is incredibly trivial - just call the
callback in your main loop to get the audio, and push it on it's way.
Doesn't get much simpler than that.

Wrapping BIO in a callback system requires hacky race systems with
multiple threads waiting on each other and hoping they finish on time.
Hardly as simple or elegant as just calling a function.

> We're dealing with computers here and no scheme, callback or 
> blocking, will ever provide perfect "glitch-free" audio in all 
> circumstances.  I can make Jack glitch on my Linux system by doing lots 
> of processing and moving windows around and such.  We must admit that 
> there are limits to what the computer can do and when you start to push 
> the processor close to those limits, no scheme will be perfect.  I just 
> wish the "callback crowd" would get off their high-horse and admit as 
> much.

(Moving windows around most definitely will not glitch jack on a
properly configured system)

You're right blocking I/O is perfectly fine in some cases - when there
is exactly one realtime audio program pumping it's audio in to
something. (Heck, jack itself pushes audio to the sound card this way!).

The problem is when you have multiple apps running, depending on each
other's audio, like Jack allows.  This situation is entirely different -
blocking I/O is crap here, and callback is the only way to go.  Blocking
may have worked well in your experience, but not on platforms like jack
that allow these sorts of things.  With callbacks you have one realtime
thread generating everything and there's no problems.  Multiple realtime
thread for every little app causes tons of problems (and puts you at the
mercy of the OS's scheduler)

But jack or no jack, a realtime app should be - well, realtime.
Deterministic.  The only difference with jack is people actually notice
then things fail because it kicks apps out, whereas on OSX or windows it
will just glitch and happily continue on.

> I'm not saying this against Dave.  Dave knows how Jack works and if 
> ChucK is to interface cleanly with Jack, the changes he suggests are 
> likely necessary to make that happen.

Well, the proof is in the pudding.  I can tell you that every single
audio app I have that does blocking IO and then shoehorns it into the
jack callback is completely unreliable.  Zynaddsubfx, ChucK, even pd
(which is a shame) - I would never, ever trust these apps in a live
scenario.

On the other hand, I'm working on a certain project that is 100%
realtime safe in the callback - it has never zombied, once, ever,
regardless of load.  I can trust it, I know it's not going to die.
SuperCollider is also designed like this, and it's rock solid in my
experience.

I want ChucK to be like that!  The advantages would definitely trickle
over to other platforms as well, just not in as obvious a way.

-DR-