[sdiy] IR Reverb
ebrombaugh1 at cox.net
Fri Feb 16 20:38:06 CET 2018
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:
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...
> 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.
>> 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
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
More information about the Synth-diy