[chuck-dev] JACK correctness part IX (callback vs. blocking)

Gary P. Scavone gary at music.mcgill.ca
Wed Sep 28 09:53:15 EDT 2005

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  



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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

More information about the chuck-dev mailing list