On Tue, 2005-01-11 at 13:09 -0500, Dave Robillard wrote: > After some investigation, yes it is. The RtAudio driver locks a mutex > right in the Jack process callback - it doesn't look like it's designed > correctly for Jack. > > Offending lines are in RtApiJack::callbackEvent. I may just write a > direct Jack driver for ChucK though - cut out the middle man. This > RtAudio has a lot of code in between the jack callback and ChucK which I > don't think is necessary, and it would be much simpler to verify ChucK > isn't doing naughty things if it used Jack directly.
There is a feature in Ingo's RT preempt patchset that allows you to do userspace atomicity debugging. I believe recent CVS versions of JACK detect this automatically and build in support for it. With this feature if your JACK client does anything non-RT safe (IOW anything that could schedule()) you get a "scheduling in user-atomic context" message with a stack trace. The first time anyone tried it, using Hydrogen, it immediately revealed a bug where they had used a non RT safe QT call in process(). Lee
