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

[Ge Wang]

On Mar 12, 2005, at 5:29 PM, Dave Robillard wrote:

> (Back from the dead!)

Welcome back.

> I have time to look at this now, but it would make the task much easier
> if someone can just tell me a few things so I don't have to wade 
> through
> so much code to figure out how everything works (frankly, that RTAudio
> stuff isn't the most pleasant code in the world to deal with):

RtAudio code may not win beauty pageants, but it works.  Except on Jack
from time to time.  Having RtAudio has made ChucK development easier
and faster.  It is quite solid, too.

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

> - Does ChucK use the callback driven API or the I/O one?  (please,
> please say the callback)

callback.

> - Where in ChucK is all the DSP dirty work done?  (ie what is the
> "master" DSP processing function)

All the DSP happens in the VM.  The native audio engine of ChucK
computes the audio before sending it to the soundcard.  The ChucK
model is completely deterministic down to the sample, and is robust
against system timers and external scheduling.  It's all in the VM.
The actual code that ticks the samples is in the shreduler,
in chuck_vm.cpp.

> - Has ChucK been written with an eye towards realtime correctness (ie
> deterministic dsp processing times), or does it do bad things like
> allocate memory and lock mutexes in the audio callback?

The model in ChucK guarantees that the synthesis is sample-accurate
and correct even when real-time breaks.  There aren't many tricks to 
keep
things real-time safe, though the virtual machine has pretty good 
control
over getting things to work nicely with audio callbacks and such.  It 
doesn't
allocate memory in the callback in steady state, but other bad things 
could
be afoot...

> Scratch most of the other questions, I've looked at some of the code 
> and
> realized some things.  Mainly that RTaudio isn't the problem, ChucK
> itself is doing some /incredibly/ evil things in the audio callback.

Yeah, like we said, there are some egregious things in parts of the 
code.
We designed the thing, however, so that bad things we identified could 
be
modularly swapped out.  At least that was the idea.

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

Best,
Ge!