On Mar 12, 2005, at 5:29 PM, Dave Robillard wrote:
(Back from the dead!)
Welcome back.
I have time to look at this now, but it would make the task much easier if someone can just tell me a few things so I don't have to wade through so much code to figure out how everything works (frankly, that RTAudio stuff isn't the most pleasant code in the world to deal with):
RtAudio code may not win beauty pageants, but it works. Except on Jack from time to time. Having RtAudio has made ChucK development easier and faster. It is quite solid, too.
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.
- Does ChucK use the callback driven API or the I/O one? (please, please say the callback)
callback.
- Where in ChucK is all the DSP dirty work done? (ie what is the "master" DSP processing function)
All the DSP happens in the VM. The native audio engine of ChucK computes the audio before sending it to the soundcard. The ChucK model is completely deterministic down to the sample, and is robust against system timers and external scheduling. It's all in the VM. The actual code that ticks the samples is in the shreduler, in chuck_vm.cpp.
- Has ChucK been written with an eye towards realtime correctness (ie deterministic dsp processing times), or does it do bad things like allocate memory and lock mutexes in the audio callback?
The model in ChucK guarantees that the synthesis is sample-accurate and correct even when real-time breaks. There aren't many tricks to keep things real-time safe, though the virtual machine has pretty good control over getting things to work nicely with audio callbacks and such. It doesn't allocate memory in the callback in steady state, but other bad things could be afoot...
Scratch most of the other questions, I've looked at some of the code and realized some things. Mainly that RTaudio isn't the problem, ChucK itself is doing some /incredibly/ evil things in the audio callback.
Yeah, like we said, there are some egregious things in parts of the code. We designed the thing, however, so that bad things we identified could be modularly swapped out. At least that was the idea.
(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. Best, Ge!