Realtime reverb algorithm with FFT

1
votes

I am trying to create/implement a realtime reverb algorithm using FFT. I've tried FDN and other simpler algorithms but they just do not sound good enough. So, doing a fast convolution by multiplying the transformed signal and the transformed impulse response is working and sounds great.

The problem as i see it is that if I want a reverb that last several seconds, that impulse response is containing 100 000+ values and since my input buffer is 256 samples so the result of the convolution is 100 255+ result values that has to be added together with previous convolution results, not to mention calculating a FFT for 100 000+ values for each buffer of 256 input samples.

There must be a better solution to this problem. Is it possible to just calc a FFT for just 256 values (+ 256 padded zeroes since it's not a circular signal). The reverb don't have to be absolutly correct, it just have to sound good.

1
audiofftconvolution

1 Answers

2
votes

You may wish to consider a "frequency delay line", or otherwise known as partitioned convolution. In short, you can break the reverb IR into several partitions, take the FFT, convolve with the input signal, and insert it to the output at a delay set to the latency of the partition in question. This is still CPU intensive for a full IR of several seconds, so...

Other tricks include feeding the Head Related Transfer Function (HRTF) into a more conventional reverb synthesis algorithm. This plays on the philosophy that the room's frequency response is represented within the first set of reflections. The HRTF can then be fed into a more conventional flat-response reverb synthesis algorithm in order to create the multiple reflections. Use the HRTF instead of the traditional comb filter.

More specifically pointed at your question, check out Fons Adriaensen's work. http://kokkinizita.linuxaudio.org/papers/aella.pdf http://kokkinizita.linuxaudio.org/papers/index.html (more interesting papers)

Explore his site for other interesting plugins and source code.

Julius O Smith of CCRMA (Stanford) also has a lot of good information out there.

I could not answer in detail here, but I hope the paper by Fons answers your question.