[sdiy] IR Reverb

[Eric Brombaugh]

I suspect that STM32 doesn't have the horsepower you'll need to do a 
useful IR reverb. There are several fairly efficient FFT in the CMSIS 
libraries from ARM but even using those the best you can do is about a 
4096 FFT running at less than 48kHz with long latency and large overlaps.

You might want to study the various FFT easter-egg modes in the source 
code for the MI Clouds module to learn more:

https://github.com/pichenettes/eurorack/tree/master/clouds/dsp

Eric

On 02/16/2018 12:24 PM, Tim Ressel wrote:
> 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
>