Hi ChucKers, The mutex in RtApiJack does nothing that would ever cause a problem with Jack _unless_ you do something that you shouldn't be doing, such as having two different threads attempting to call data-access functions in a given RtApiJack instance. The mutex is there simply to protect audio buffer access from unexpected, outside intervention. Perhaps it is unnecessary but I decided to keep it because: 1. It doesn't do any harm (assuming you are using RtAudio as expected, which is the case in ChucK); and 2. It provides a layer of protection that could be necessary in some unforeseen programming context. Regards, --gary On Sep 28, 2005, at 1:21 AM, Dave Robillard wrote:
On Mon, 2005-26-09 at 11:55 -0400, Ge Wang wrote:
I must admit that I don't know Jack and would like to ask Linux/Jack users here to give it a spin under various conditions. Please let us know how things fare. Dave, Florian, Leonard - can you guys give this a try?
It's working muuch better: chuck --loop and adding/removing rapidly with a heavily loaded system (doomed to horrible death before), not an xrun to be found.
There is still that mutex being locked in RtApiJack::callbackEvent which will cause problems (mostly with many jack clients running) Is it even necessary? I can't see any immediately obvious reason why it needs to be there, but admittedly I havn't looked very thoroughly.
Pedanticness aside - nice work. I can't seem to actually find your callback anywhere though - it looks like you're passing a NULL callback (via the default param value) to all the initialisation functions to me (it's a bit twisty to navigate). Where's the actual chuck DSP callback live?
Cheers,
-DR-
_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev