[sdiy] IR Reverb
ebrombaugh1 at cox.net
Fri Feb 16 20:00:28 CET 2018
That's correct - window, FFT, multiply, IFFT, overlap & add.
Now do that multiple times at different window sizes and time offsets,
sum up all the results. Amazingly enough, despite all the hokey-pokey it
ends up being fewer operations than a straight FIR.
On 02/16/2018 11:48 AM, Tim Ressel wrote:
> Ah, okay. But you have to also do inverse FFTs, yes? So the FFT gets the
> input into the frequency domain which gets multiplied by the IR, then an
> iFFT gets you back to time domain. Overlap reduces congruity issues. Am
> I getting that right?
> On 2/16/2018 10:11 AM, Eric Brombaugh wrote:
>> Yes - a brute force requires 100k MACs / sample.
>> An FFT approach reduces the the total number of multiply / add
>> operations required to do a convolution due to the optimization of the
>> "fast" algorithm. FFTs reduce the N^2 operations of a DFT to N*log(N),
>> so the larger the transform you can get by with, the more advantage
>> you'll see. The downside is that FFTs introduce a lot of latency, so
>> to get around this transform-based convolution engines will typically
>> subdivide the process into a small & fast FIR to handle the early
>> results, followed by gradually larger and larger FFTs to handle the
>> later results.
>> On 02/16/2018 10:53 AM, Tim Ressel wrote:
>>> Thanks for all the replies! So the concept sounds simple enough. I
>>> get the sense the issue is going to be processing time. Am I wrong,
>>> or would a brute-force approach to a 2-second reverb time require
>>> 100K MAC cycles per sample? I found some open-source packages that
>>> use FFTs to do this. I was under the impression FFTs would be less
>>> fast than other methods.
>>> Ever get the feeling you're opening Pandora's Box only to find a can
>>> of worms inside?
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
More information about the Synth-diy