On Sat, 2005-12-03 at 23:42 -0500, Ge Wang wrote:
I noticed RTaudio has a blocking I/O and a callback-driven API. The blocking I/O version will need to be disabled completely for the Jack driver - you can't do that sort of I/O with jack, and there's no way of shoehorning it in there (nicely). There is a Big Nasty Mutex(TM) in the RTAudio jack callback function that needs to go away, which seems to be protecting this I/O based API, but may have other purposes I havn't seen yet (I just took a cursory glance)
We need to look into this Big Nasty Mutex. I will move this thread to chuck-dev and we will figure it out there.
The mutex is no big deal, you can literally just comment it out and have things work. If you're using the callback API, it doesn't seem to do anything. It's wrong and needs to be fixed, but the real problem is how chuck uses the audio lib - I've (hackily) removed the mutex in my tree, and ChucK still dies just about as often.
(looping and checking a "finished processing" flag, and _sleeping_ for a while if it's not?!!). Running a race between the audio callback and some other thread like this just can't happen, it will need to be changed for any sort of decent realtime performance.
This in steady state is not nearly as bad as it looks. The callback should be using the result of the previous block from the synthesis process, and only allows a tiny wait to alleviate potential jitter. The blocking never happens in most cases. We could make this more stable by computing a buffer ahead at the cost of slightly higher latency, but we currently don't.
"In most cases" is exactly the problem. So ChucK isn't going to fail and ruin my live performance.. in most cases? Great! :) There can't be one thread doing the audio, and the audio thread peeking at it to see if it's done yet, and expect good RT performance. This is going to have to be changed. Running a race between threads is just not a good idea, and that's exactly what this is - a race. On a properly configured realtime system, the audio thread will be the highest priority thing there is, so you ARE going to lose sometimes. It's much less efficient anyway. Somehow, the audio callback is going to have to be where the audio processing is done - it has to "drive" everything, so to speak. This way the audio callback is deterministic, and does all the DSP directly, instead of attempting to syncronize with some other thread and /blocking/ intentionally. I hope it's not that severe an architechtural change, but for things to work well and be trustworthy, that's what has to be done. :/ -DR-