Last night I was playing around in HourGlass with the built-in convolution effect inserted for about half an hour. Suddenly, as I was tweaking the wetdry mix knob, HourGlass hung irreversibly. I guessed immediately it had to be a locking error. Sure enough, there was code like this in the convolution effect :
…the audio processing…
Due to luck or something it took lot of time before this error manifested in HourGlass hanging. The correct code is something like :
… the audio processing…
Back a few months ago when I changed the locks in HourGlass to be WDL mutexes instead of QMutexes, I suspected an error like this could have creeped in, and here is at least one of them. 😦 Anyway, it’s fixed now and the fix will be in the next release…
Actually locking should be done via an automatic lock handler object so the code would become something like :
… the audio processing…
But for some unexplainable reason I hadn’t done the locking like that in the convolution effect…(Most code paths involving mutex locking in HourGlass use the automatically managed method.) At the moment the convolution effect still doesn’t use the automatically managed method, because there might be some reason the more unsafe method has been used in the code, I will need to investigate that.
So why are these kinds of dangerous potentially hanging locks needed anyway? They are used to synchronize execution of multiple threads. (It’s very common in audio applications there are at least 2 threads : the main/GUI thread and the audio processing thread.) In the convolution effect, the same lock is also locked in the code that handles the GUI knob for the drywet mix of the effect. (But there the locking was done correctly.) However, because the locking was incorrect in the audio thread, tweaking the GUI knob eventually lead to the application hanging (because it’s undefined/illegal behavior to “leave” a mutex that wasn’t first entered.) There are ways to deal with these kinds of synchronization issues without mutex locks, but those invariably make a lot of the code much more complicated and error-prone too…The primary motivation to do less or no locking would be to increase CPU efficiency and decrease the chance of audio glitches, but that hasn’t been a primary concern in HourGlass, as it’s intended to be a studio composition tool, not a live performance instrument.
(In any case, the built-in convolution effect is a bit lame, I would like to add various processings for the loaded impulse responses etc…It also looks like the wetdry mix parameter isn’t even automatable at the moment, even though it used to be…Even more, convolution isn’t really even among my favorite effects to use, but I would still like to work on it for HourGlass, as it’s a relatively “cheap” and straight-forward way to achieve spatial effects. Such effects could of course be added outside of HourGlass, but having such things integrated allows more complicated things than is possible by effecting the final rendered result in a DAW…This also reminds me the probabilistic audio sends into the aux channels should finally get automation for the send level and send probability parameters…Argh, so many things that should be done…)