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-