[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