getCallbackLock considerations


#1

in my host i have a directed graph with every node a plugin. in some cases the user can massively modify the order, number and connections in the graph, so i have to recalculate the new order of processing and rebalance connections. since the host is playing while the user is doing this, i have to ScopedLock (on main audio thread CallbackLock) the recalculation of the graph weights and order, cause i can’t mess with connections while i’m processing them.
but if the calculation takes a while, then i’m blocking too much the audio thread, and so i start to produce zipper noise (at least on alsa and jack on linux).
how would i address this kind of stuff ? maybe i have to check atomically in the audio processing for a iShouldLeaveProcessingNow while the graph is recalculated (think when i’m restoring it from a session state) or there are better solutions ?


#2

I reckon the sensible way to do it is to build a new graph in a different thread, and when it’s ready just swap it over with the current one. It can be a bit fiddly to make sure state is carried over correctly, but avoids any clicks or glitches.


#3

yeah that could be the way to go. for now, i’ve done something simpler without introducing a stronger complexity that in the long run could be hard to maintain. it works, but obviously if the graph is big and intricated then sound could stop for a while, anyway less than be disturbing.
and the lucky is that i use only a directed graph without feedback loops (that could make my head explode definately)… !

thanx jules for the response, i’ll take into account your ideas :slight_smile:


#4