# How do real-time convolution plugins process audio so quickly

Okay, so in Logic Pro I can load up a Space Designer plugin (convolution reverb) with an impulse that's 9.1 seconds long, turn my mic on, and get real-time convolution reverb as the mic records incoming audio.

My question is: How could this be possible? My I/O buffer size is 32 samples. Is my computer capable of performing the convolution of a 401,310 sample impulse with a 32 sample block of audio in under 0.0007 seconds? If so, what kind of black magic do I need to get my own convolution reverb to do this?

I should mention that I am trying to develop real time convolution in C with portaudio. It works great when it's not real-time, but it's way too slow in real-time (the convolution I mentioned above takes 0.8 seconds using frequency-domain convolution which is supposed to be faster for impulses of that size, no?

Anyway any insight would be helpful, as I would really like to understand how this kind of real-time processing is possible.

• I won't post over Olli's nice answer, where he shows a particular way of speeding up the operation. Yet, for modern computers 0.7 seconds is more than enough to convolve such a signal and you actually do not need any algorithmic optimizations (Of course, any smart person would first make the algorithm better). So, all you need to do is to effectively make use of the particular structure of your kernel, SSE/AVX instructions, and parallelization. For the codes you cannot optimize, leave to the compiler. They are pretty good at optimizations as well. – Tolga Birdal Sep 20 '15 at 15:44
• I'm not sure that's a correct.statement. A 9.1s impulse response sampled at 44.1 kHz takes about 18 billion multiply add operations per channel. That's out of range for most "normal" processors. Accelerator hardware can help but it's typically limited by memory bandwidth: you simply can't load the coefficients fast enough especially if they are not in cache. – Hilmar Sep 20 '15 at 16:05
• @Hilmar : Just wondering where you get 18 billion from? Direct calculation of 401,310 filter taps yields 161 billion ($N^2$) and $N\log N$ gives 2.25 million. – Peter K. Sep 21 '15 at 14:37
• @Peter: It's basically filter length times sample rate. You need 400k mpy/adds per sample and you have 44.1k samples per second. – Hilmar Sep 22 '15 at 20:34

Real-time low-latency partitioned convolution reverb with a long impulse response works by dividing the impulse response into unequally sized partitions. The shortest partitions (blocks) are at the beginning of the impulse response, and the partition length grows towards the end of the impulse response:

Each partition length can be processed separately, giving for each a latency that is for fast Fourier transform (FFT) -based convolution perhaps a couple of times the partition length. Convolution outputs for all partition lengths are summed forming the final composite output. When partitioning the impulse response, the partition of a particular length must not appear before the time that equals the latency of convolution of that partition length. A time-domain finite impulse response (FIR) filter can be used for the beginning of the impulse response because that may be more efficient than doing the low-length convolution by FFT.

What is the optimal partitioning for a given impulse response length and the optimal split point between time-domain FIR and FFT convolution should be tested on the target platform. A challenging aspect of non-uniform partitioned convolution is scheduling of the work.

Non-uniform partitioned convolution was popularized by William G. Gardner, Efficient Convolution without Input-Output Delay, J. Audio Eng. Soc., Vol. 43, No. 3, 1995 March, available online at http://www.cs.ust.hk/mjg_lib/bibs/DPSu/DPSu.Files/Ga95.PDF.

• Nice answer, Olli! – Peter K. Sep 20 '15 at 22:53