[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
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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
>
More information about the chuck-dev
mailing list