On Sun, 2005-23-01 at 11:39 -0500, Ge Wang wrote:
Dave Robillard, from the Linux Audio Developer List, was good enough to look through our Jack code for ways to improvements and have found some. We hope to integrate the changes soon. What do you think Dave?
(Back from the dead!) 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): 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) - Does ChucK use the callback driven API or the I/O one? (please, please say the callback) - Where in ChucK is all the DSP dirty work done? (ie what is the "master" DSP processing function) - 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? Personally I would rather just not deal with RTaudio and implement a native jack driver, but I understand why you wouldn't like that. Hopefully fixing the jack support will make other things like sndpeek (which I have never, ever gotten to work) and whatever else (STK?) work better under realtime Jack/Linux Cheers, -DR-