JACK correctness part IX (callback vs. blocking)
Greetings! On the recommendation of Dave Robillard, Florian Schmidt, and other Linux audio developers, we have implemented callback functionality for real-time audio, while keeping the blocking functionality. Both are accessible using command line flags (--callback vs. --blocking). The default is callback. Perhaps not surprisingly, this is much more stable for small buffersize on all platforms except windows directsound. Hopefully, it is a step in the right direction for alleviating problems running chuck under Linux/JACK. The newest version is in CVS: cvs -d :ext:anon-chuck@cvs.cs.princeton.edu:/cvs checkout chuck_dev password: (hit enter) The code is in chuck_dev/v2/ 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? Thank you very much! Best, Ge!
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-
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!
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
participants (3)
-
Dave Robillard -
Gary P. Scavone -
Ge Wang