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 ?
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.
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 