Rooms!

Convolution Reverb Changes in Rooms! 6.1

The computation of convolution reverb in Rooms!, which has previously used concurrent processing and distributing of work to several CPU cores, has undergone considerable changes in Rooms! 6.1

We wanted to make the convolution engine fit for using it as an audio unit. The 6.0 implementation worked fine with some AUv3 hosts, like Audiobus, but not so well with others, like GarageBand. It is as if GarageBand is continuously running high priority threads, hindering other apps performing work outside of the audio callback in lower priority threads, even on performant devices with many cores. Hence we were forced to move all processing to within the audio callback. Considering the high single-core and vector performance of current CPUs, this is not a problem. Even an iPad mini 2 meets the demands of the job (with not too long impulse responses and not too short buffer durations).
It then turned out that distributing the work to two CPU cores, which was quite helpful when the calculation was done concurrently to the audio thread, gives almost no speedup when done within the audio callback, at least not on recent devices. Only with an iPad 2 we were able to measure a few saved milliseconds with medium-sized impulse responses. Hence we decided to drop the parallelisation as well. Now the complete work is done within the high priority audio thread, incidentally avoiding the risks of thread priority inversion.
In the 6.0 implementation it was not so clear what should be displayed as the convolution time when you activate the corresponding option in the Settings view. The average time needed for the concurrent tail calculation seemed to be a good choice. In the 6.1 implementation, the answer is simple: It is the full time of the convolution calculation within the audio callback.
On the other side, in the 6.0 implementation the handling of performance bottlenecks was easy: When the concurrent processing was not finished at the next audio callback, a timeout was diagnosed and the concurrent processing was cancelled. For the 6.1 implementation, a new way to define and to deal with timeouts was needed. In the Settings view there is now a slider where the user can configure the maximum time available for calculating the convolution. When this time is exceeded, the convolution is ended prematurely, and only a part of the impulse response is employed. Usually you can leave this slider in the rightmost position, which means 80% of the buffer duration. When other audio apps get into performance trouble, e.g. apps in an Audiobus processing chain, you can reduce the time that is reserved for the convolution reverb.