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

[Dave Robillard]

On Mon, 2005-14-03 at 03:05 -0500, Ge Wang wrote:
> 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.

I think sndpeek might have seperate issues.   I've never even managed to
get a window to display for any amount of time, realtime or no.


> 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.

I would rephrase it: "The current scheme MIGHT have the audio
pre-computed before the callback".  This is one of those things best
explained with questions:

- How do you know your thread is going fast enough?  Or even too fast?
- How do you know how much audio is actually demanded of you?
- What about offline processing?  (in theory)
- Who gets more scheduling priority?  Your thread?  Jack thread?
- Will usleep() return on time?  Will pthread_mutex_lock()?  Will the
synthesis thread get back in time?
- What does "in time" mean anyway?  How much time do we really have?

The answer to every one of these question is "I dunno".  It's all about
determinism.  Not really a specific Jack thing, it's just hard realtime
requirements.

pthread_mutex_lock is not deterministic.  usleep() isn't deterministic
(it is perfectly acceptable for usleep(1) to sleep for 10 /seconds/ if
it wants to).  Whether or not the other thread makes it back in time is
not deterministic.

The problem with attempting to wait on the other thread is - how long
can you wait?  You have no way of knowing what an acceptable time to
wait is.  Jack does, but you don't.  So, if you don't wait long enough,
you won't get your audio.  If you wait too long, jack will kick you out.
Having the other realtime thread running in parallel causes a whole
whack of scheduling problems too, which might be a cause of a lot of the
problems (I'm no kernel hacker) - the idea behind Jack is that there
is /one/ realtime priority audio thread that does everything and knows
what is going on, that's where the robustness comes from.

I find the best way to think about it is in terms of offline processing,
ie everything moving reeally slowly - imagine the audio callback being
called every 5 seconds.  Everything should still function perfectly well
(gigantic queues of timestamped events aside).  Currently you'd have a
realtime thread going crazy, generating way, way too much audio with
nowhere to store it (of course, the opposite is what's happening right
now).  Everything is so, so much nicer when the audio callback just says
"compute and give me 64 samples now".

To be honest, I don't know exactly when jack will decide it's had enough
of misbehaving clients, I'm not a jack developer.  I understand what you
mean, time is time.  Unfortunately it doesn't work that way, but I
freely admit to not really knowing how jack itself knows the difference.
I assume the lack of determinism just rears it's ugly head the your
callback takes too much time, but there could be more clever things
going on.  No idea - I just know that making the audio callback
deterministic is what you have to do (ie it's a known requirement
documented alongside Jack's API), and that my personal experience (and
reading code) has backed that up.

It's easy to get bitter at Jack for being more picky about these things,
but realtime systems should be coded properly regardless - determinism
is king.  I'm sure that on OSX if you run ChucK alongside a few other
audio programs and really thrash the CPU, you'll get lots of dropouts as
well.  Ever tried it?  (I don't have a Mac)

Sorry if I don't understand this stuff very well at a super-low level, I
just know what I have to know as an app developer..  I learned all this
the hard way, that's for sure.

Cheers,

-DR-

P.S.  I unintentionally come off sounding really negative here..  I
really think ChucK is the greatest thing since sliced bread.  Bravo. :)