11 Jan
2005
11 Jan
'05
4:20 p.m.
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