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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev