ChucK Jack correctness (Formerly: Re: [linux-audio-dev] [semi-OT] EEL 0.1.0 + ChucK)

From: Dave Robillard <drobilla@email-addr-hidden>
Date: Tue Jan 11 2005 - 20:09:18 EET

On Tue, 2005-11-01 at 12:17 -0500, Dave Robillard wrote:
> On Tue, 2005-11-01 at 01:48 -0500, Ge Wang wrote:
> > >> I need the guarantee that the audio thread of the language/VM is
> > >> 100% realtime safe (ala the jack guidelines).
> > >
> > > That's a primary design goal for EEL (which is the main difference
> > > from scripting languages in general)
> >
> > (Hmm, how do you make a synthesis language 100% realtime safe?)
> >
> > The ChucK model guarantees data consistency (it will always generate
> > the right samples), and does its best to be on-time. The only thing
> > that
> > would be needed to make it hard RT capable is to improve mechanisms
> > that would know when deadlines are missed (which is quite easy in the
> > framework) - otherwise, the language model, with time built-in,
> > naturally
> > captures many important aspects of RT programming.
>
> I mean RT safe in the jack sense - not calling any blocking functions in
> the audio thread (ie no allocating memory, locking mutexes, etc.)
> Sorry, bad terminology on my part.
>
> ... Is this why ChucK is always zombie-ing on me? :]

After some investigation, yes it is. The RtAudio driver locks a mutex
right in the Jack process callback - it doesn't look like it's designed
correctly for Jack.

Offending lines are in RtApiJack::callbackEvent. I may just write a
direct Jack driver for ChucK though - cut out the middle man. This
RtAudio has a lot of code in between the jack callback and ChucK which I
don't think is necessary, and it would be much simpler to verify ChucK
isn't doing naughty things if it used Jack directly.

(I'd bring this up on the ChucK list but subscribing isn't working for
whatever reason)

-DR-
Received on Wed Jan 12 00:15:04 2005

This archive was generated by hypermail 2.1.8 : Wed Jan 12 2005 - 00:15:04 EET