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

[Gary P.Scavone]

Hi Everyone,

I hope to have some time later this week to look at the RtAudio Jack 
code, though it appears that the main problems lie elsewhere in the 
ChucK code.  With respect to the "big fat mutex", it is there to 
protect _all_ the RtAudio functions from the user making multiple calls 
simultaneously (perhaps on a multi-processor system) that might 
interfere with each other.  In the long run, it might be unnecessary 
and perhaps we can make do without it, but I chose to be "safer" than 
"sorrier".

I'll add "my two cents" with regard to the scheduling:  The Jack 
community espouses the callback paradigm as the only solution to 
realtime audio i/o ... I've been hearing this loudly for the last 4-5 
years.  Then there's a bunch of us that used to do things with blocking 
calls and know how easy it was to make them work with the same 
consistency as the callback paradigm.  This last sentence will raise 
arguments like "there is no way that a blocking paradigm can be as 
robust as a callback paradigm".  I'm not here to convince ... I simply 
know from experience.  In fact, I find it much easier to work with 
blocking functions and embed them in threads to "simulate" a callback 
scheme ... the reverse is nearly impossible (yes, I agree with Dave 
that my attempt to "shoehorn" Jack into a blocking scheme is not 
robust).  We're dealing with computers here and no scheme, callback or 
blocking, will ever provide perfect "glitch-free" audio in all 
circumstances.  I can make Jack glitch on my Linux system by doing lots 
of processing and moving windows around and such.  We must admit that 
there are limits to what the computer can do and when you start to push 
the processor close to those limits, no scheme will be perfect.  I just 
wish the "callback crowd" would get off their high-horse and admit as 
much.

I'm not saying this against Dave.  Dave knows how Jack works and if 
ChucK is to interface cleanly with Jack, the changes he suggests are 
likely necessary to make that happen.

--gary

On Mar 13, 2005, at 8:35 PM, Dave Robillard wrote:

> On Sun, 2005-13-03 at 03:35 -0500, Ge Wang wrote:
>> Greetings,
>>
>> This is continued from the JACK correctness thread.
>>
>> The problem has been plaguing Jack/ChucK users (all 3 of them by now).
>> Let's figure it out!
>>
>> Dave R. or Gary S. please help lead the way!
>>
>> Best,
>> Ge!
>
> Well, I've done about as good a job as possible at screwing up this
> cross-list conversation.  Anyway!  Summary:
>
> Basically, the problem is that ChucK is a horrible realtime jack client
> (ie it zombies all the time) because the audio callback sleeps, waiting
> for ChucK's synthesis thread to finish.
>
> The solution is to make the audio callback thread the synthesis thread
> (ie make the audio callback drive all synthesis), eliminating this 
> race.
> This is how things "should" be.  Making the callback drive everything 
> in
> a deterministic way would make ChucK a rock-solid jack client in
> realtime.
>
> I can see why this might be a nuisance though, because ChucK is 
> probably
> driven by wall clock time (judging from the timing system of the
> language).  It could be not that difficult though - I'm not sure how 
> the
> ChucK vm core works yet, just the part that interacts with the audio
> callback.
>
> Essentially all we actually need is a function that can compute n
> samples of chuck audio on request.
>
> So I guess it comes down to either:
>
> a) It's possible - how to do it?
>
> b) It's not possible - why, and how can we make it at least a bit
> better?
>
> Cheers,
>
> -DR-
>
>
>
> _______________________________________________
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev