# Conceptually, how does real time convolution reverb work?

I've got an impulse response of a hall, it's 10 seconds long.

Now say I want to apply this reverb to a wav file of some singing. I would perform a convolution of the data in two wav files and that the result would be a third lot of data, this time with the reverb. Great.

But how would this actually work in a real time setting, in a program like GarageBand, using a live input like an electric guitar?

Garageband can't convolve the full guitar track because it doesn't yet exist (because it's being played live!) One way that I thought of, was if the program performed the convolution on say, the 256 most recent samples of guitar input.

But this raises 2 issues:

Would the computer be able to perform so many convolutions every second? And surely this introduces some sort of delay while waiting for the calculations to be processed?

If anyone could help explain, that would be great.

• every sample smp of the input/initial sound is multiplied by the impulse response on linear domain, like a vocoder only common partials of the two sound being output... Apr 24, 2014 at 19:57
• Good answer to this question is this. Oct 4, 2020 at 17:50

It comes down to latency vs. complexity. If your filter is 10 seconds long, you need to store the audio data of the last ten seconds and then you are able to calculate the current output audio sample with a latency of basically zero (ignoring the time required for calculations here) simply by doing:

$$y[0] = \sum_{k=0}^{l} x[-k] \dot h[k]$$

where $l$ is the length of the impulse response $h$ and $x[0]$ is always assumed to be the current sample. While this gives you basically zero lag, it boils down to the performance of naive convolution which can easily be too much especially if the impulse response is very long.

Now you could use techniques such as overlap-save which already perform convolution of very long signals by splitting the signal up and performing the convolution in chunks. However, to be able to calculate the output you first need to capture all the input samples for one chunk so this defines your latency (again ignoring the calculation time). The efficiency of these algorithms is usually in between the direct convolution method and the pure FFT method and the amount of calculations per sample will be less for longer chunks at the cost of latency.

The problem with overlap-save is that the chunk needs to be at least the size of the impulse response so for a 10 second response, the latency will be at least 10 seconds, hardly real-time. For this case so-called partitioned convolution algorithms have been developed that split both, the impulse response and the incoming signal. I've found a very good paper describing these techniques here (Click me) so I will just link it. I can hardly describe it better than they do.

From what I heard, there should be no more than 3-5ms latency or a good musician will notice the delay.

To add to jan's answer: Most commercial reverb effects (plug ins or hardware) are NOT based on convolution with an impulse response but are based parametric algorithms in some network configuration. This has a bunch of advantages:

1. Less memory
2. Less MIPS
3. It's parametric, so different parameters like "room size", "reverb time" , "color", etc. can be adjusted continuously and in real time.
4. If done well, it actually sounds better
• Would down-vote if I could... The question was specifically about convolution reverb, and this answer is specifically about algorithmic reverbs... And it is reckless to say that algorithmic sounds better because it just sounds different. Take Altiverb, for example... it is an amazing sounding convolution reverb engine... A good pair of headphones, close your eyes, and you're inside Sydney's opera house. And you CAN tweak parameters like length, color, etc. Mar 21, 2019 at 9:52

Yes, real time convolution reverbs do windows of convolution, but interestingly, they don't actually do explicit convolution. It turns out that convolution in "time space" is the same as multiplication in "frequency space". What this means is that if you do an FFT of your window of guitar music, and multiply it by a previously generated FFT of your reverb, then do an IFFT to put it back into time space instead of frequency space, you'll have your convolution reverb. Turns out to be a lot less processing to do it that way, so machines can do this stuff in real time (: