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-