[sdiy] IR Reverb

Tim Ressel timr at circuitabbey.com
Fri Feb 16 20:24:08 CET 2018


Still, even with all that jigery-pokery, we're going to need a bigger 
boat, er, processor. I'd like to avoid processor choices that needs 
pricey tools. STM32 would be nice. Of course some good ol' fashion 
assembly code, highly optimized, would help things. Its been a while 
since I went down that rabbit hole. I wonder if someone has an optimozed 
FFT library for Cortex Mn...

--timbo


On 2/16/2018 11:00 AM, Eric Brombaugh wrote:
> 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.
>
> Eric
>
> 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?
>>
>> --tim
>>
>>
>> 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.
>>>
>>> Eric
>>>
>>> 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
>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy

-- 
--Tim Ressel
Circuit Abbey
timr at circuitabbey.com



More information about the Synth-diy mailing list