[chuck] Bus Error - Trying to run ChucK for the first time

[Dave Robillard]

On Sat, 2005-12-03 at 23:42 -0500, Ge Wang wrote: 
> > I noticed RTaudio has a blocking I/O and a callback-driven API.  The
> > blocking I/O version will need to be disabled completely for the Jack
> > driver - you can't do that sort of I/O with jack, and there's no way of
> > shoehorning it in there (nicely).  There is a Big Nasty Mutex(TM) in 
> > the
> > RTAudio jack callback function that needs to go away, which seems to be
> > protecting this I/O based API, but may have other purposes I havn't 
> > seen
> > yet (I just took a cursory glance)
> 
> We need to look into this Big Nasty Mutex.  I will move this thread to
> chuck-dev and we will figure it out there.

The mutex is no big deal, you can literally just comment it out and have
things work.  If you're using the callback API, it doesn't seem to do
anything.  It's wrong and needs to be fixed, but the real problem is how
chuck uses the audio lib - I've (hackily) removed the mutex in my tree,
and ChucK still dies just about as often.

> > (looping and checking a "finished processing" flag, and _sleeping_ for 
> > a
> > while if it's not?!!).  Running a race between the audio callback and
> > some other thread like this just can't happen, it will need to be
> > changed for any sort of decent realtime performance.
> 
> This in steady state is not nearly as bad as it looks.  The callback 
> should be
> using the result of the previous block from the synthesis process, and 
> only
> allows a tiny wait to alleviate potential jitter.  The blocking never 
> happens in
> most cases.  We could make this more stable by computing a buffer ahead
> at the cost of slightly higher latency, but we currently don't.

"In most cases" is exactly the problem.  So ChucK isn't going to fail
and ruin my live performance.. in most cases?  Great! :)

There can't be one thread doing the audio, and the audio thread peeking
at it to see if it's done yet, and expect good RT performance.  This is
going to have to be changed.  Running a race between threads is just not
a good idea, and that's exactly what this is - a race.  On a properly
configured realtime system, the audio thread will be the highest
priority thing there is, so you ARE going to lose sometimes.  It's much
less efficient anyway.

Somehow, the audio callback is going to have to be where the audio
processing is done - it has to "drive" everything, so to speak.  This
way the audio callback is deterministic, and does all the DSP directly,
instead of attempting to syncronize with some other thread
and /blocking/ intentionally.

I hope it's not that severe an architechtural change, but for things to
work well and be trustworthy, that's what has to be done. :/

-DR-