[chuck-dev] JACK correctness part IX (callback vs. blocking)
Ge Wang
gewang at CS.Princeton.EDU
Wed Sep 28 02:00:01 EDT 2005
Hi Dave and all,
> 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.
That's great to hear! Thank you for checking this out, and of course for
suggesting to implement the callback functionality in the first place.
> 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.
I believe it is necessary currently, though we will look into it more
with Gary's help to figure out the conditions under which it may be
blocking.
> 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?
under callback mode:
in Digitalio::cb2( ... ) in digiio_rtaudio.cpp:
vm_ref->run( buffer_size );
this calls an overload Chuck_VM::run( t_CKINT ) in chuck_vm.cpp that takes
the number of samples to be computed. The samples are computed here:
m_shreduler->advance();
Thanks again!
Best,
Ge!
More information about the chuck-dev
mailing list