Any free, real-time convolution reverb libraries out there?

Hello JUCErs,

What do you use for convolution reverb in your plugins? In-house built reverb(s) or something open-source?
Do you know of any free, real-time convolution reverb libraries out there?

Any help is much appreciated!

Cheers!

wdl from cockos has a convolution engine that works fine :
http://www.cockos.com/wdl/

Juce may have one soon in the upcoming DSP module (?)

1 Like

Thanks for the fast response!

I’ve read that people talk about replacing/replacing-on-intel-platforms the FFT algorithms in the Convolution engine of WDL with the Intel IPP. Do you think I should do that as well? (my case is, I have a sampled piano and just want to add a nice effects section for it, so it definitely shouldn’t add any perceptible delay)

Also, is there any public source of this upcoming DSP module for JUCE? I’ve looked in the repo, but there doesn’t seem to be such a new module added to the development branch?

Changing the fft algo is just about performance, not about “perceptible delay”. You can already do the convolution without added delay with WDL as it is. But changing the fft within the engine to the ipp one will improve the performance yes.

There’s no public source of the upcoming dsp module afaik.

1 Like

The wdl convo engine can’t cope with IRs longer than 0,5 seconds unless you replace the fft with IPP.

AudioTK has also a convolution class but I didn’t check it.

1 Like

really? I think already used it with some 10sec IR @44k and did not notice any particular issue.
I’m pretty sure that it’s the engine they use in the Reaverb vst plugin that comes with Reaper, so you can test it there

@olilarkin it would be awesome if you comment on the Convolution engine in WDL.
How about the version in your fork, WDL-OL - is it any different?

I tested it on a fairly moderate system (2012 Macbook pro). But curiously the Reaverb plugin behaves similar (I do get glitches when loading longer impulses) so maybe my system is a bit weird - however every other convolution engine (reverberate, max msp convolution, reverence, KONTAKT) does not have these problems.

I am using Olis fork btw, but it is not different from the tale version (except for some examples IIRC)

Tales version of WDL has and enhanced convoengine with multithreading support. I’ve used the convoengine very successfully

Here is some source code from a juce project I am working on that uses it.

EDIT->updated source code because there was a bug

1 Like

Thanks so much for joining in on the discussion, Oli!

When you say you’ve used the convoengine very successfully, do you mean Tale’s version?

@chrisboy2000 I’ve had success with the WDL_ConvolutionEngine_Div variant.

I am testing with your code and it does glitch a lot (the convo engine that is) with a 3sec impulse response.

BTW, I had to change this method in order to run it:

void ConvolutionReverb::prepareToPlay (
    int estimatedSamplesPerBlock,
    double sampleRate
)
{
    // Detect a change in sample rate.
    if (sampleRate != mSampleRate)
    {
        mSampleRate = sampleRate;

        if (mIRAudioSampleBuffer != nullptr)
        {
// <change>
            // ... if calls are already scheduled
            mLoadThreadToAudioThreadCallQueue.synchronize ();

// </change>
            updateConvoEngineIR (
                mIRAudioSampleBuffer->getNumChannels (),
                mIRSampleRate
            );
        }

        mDryLevelSmoother.setTimeMS (cSmoothTime, mSampleRate);
        mWetLevelSmoother.setTimeMS (cSmoothTime, mSampleRate);
    }
}

I had to add the sync call because on first run, the run method would be finished at prepareToPlay time, but no processBlock was called to update the IR sample rate and the method doesn’t schedule the new update - it directly executes it. Probably it should just schedule it too?

I guess I must replace the FFT with the one from IPP.

I have a wdl version using IPP for the convolution in my repo which you could use so you don’t need to write the IPP glue code yourself…

1 Like

I’ve tested pretty much everything mentioned here in this thread - both default and _Div version of the convoengines in WDL, WDL-OL, WDL-TALE and WDL-OL with FFT replaced with intel IPP’s FFT.

Tale’s version of WDL’s convoengine (the WDL_ConvolutionEngine_Thread) works best in my tests.
Second is the WDL-OL’s convoengine with intel’s IPP FFT.

Something I haven’t tested and expect to perform even better - Tale’s WDL_ConvolutionEngine_Thread with intel IPP’s FFT.