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

[Dave Robillard]

On Sun, 2005-23-01 at 11:39 -0500, Ge Wang wrote:
> Dave Robillard,
> from the Linux Audio Developer List, was good enough to look through our
> Jack code for ways to improvements and have found some.  We hope to
> integrate the changes soon.  What do you think Dave?

(Back from the dead!)

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):

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)

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

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

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

Personally I would rather just not deal with RTaudio and implement a
native jack driver, but I understand why you wouldn't like that.
Hopefully fixing the jack support will make other things like sndpeek
(which I have never, ever gotten to work) and whatever else (STK?) work
better under realtime Jack/Linux

Cheers,

-DR-