dsp::Oversampling class performance

[lcapozzi]

Hi guys,
I don’t know if I’m doing something wrong, but looks like the dsp::Oversampling is not performing good as expected.

I have an upcoming distortion plugin that, as obvious, shows a lot of aliasing if not oversampled.
I’m using the dsp::Oversampling class, but to get close to the performance of a competitor’s 4x oversampler, I have to set mine at 16x

RED: target, hardware unit | BLUE: My plugin, 16x oversampling
Notice the aliasing still there

RED: target, hardware unit | BLUE: Competitor’s plugin, 4x oversampling
Very minimal aliasing.

What I’m doing is:
create the oversampler in MyPlugin::MyPlugin() constructor
oversampling.reset (new dsp::Oversampling<float> (2, log2(OSAMPFACTOR), dsp::Oversampling<float>::filterHalfBandPolyphaseIIR, true));

in prepareToPlay i have: oversampling->initProcessing(static_cast<size_t> (samplesPerBlock));

in process I have:

dsp::AudioBlock<float> oversampledBlock;

setLatencySamples (audioCurrentlyOversampled ? roundToInt (oversampling->getLatencyInSamples()) : 0);

// Upsampling
if (audioCurrentlyOversampled)
{
    oversampledBlock = oversampling->processSamplesUp (context.getInputBlock());
}

auto pluginContext = audioCurrentlyOversampled ? dsp::ProcessContextReplacing<float> (oversampledBlock)
: context;

//My DSP code here

if (audioCurrentlyOversampled)
{
    oversampling->processSamplesDown (context.getOutputBlock());
}

Is there anything wrong I’m missing or the dsp::Oversampling class is underperforming?

Thanks!

[JeffMcClintock]

The quality I think depends on not only the oversampling ratio, but also on the quality of the downsampling filter. That might explain the disparity.

[pflugshaupt]

Look at the constructor of the juce Oversampling class.

        auto gaindBStartUp    = (isMaximumQuality ? -90.0f : -70.0f);
        auto gaindBStartDown  = (isMaximumQuality ? -75.0f : -60.0f);
        auto gaindBFactorUp   = (isMaximumQuality ? 10.0f  : 8.0f);
        auto gaindBFactorDown = (isMaximumQuality ? 10.0f  : 8.0f);

Even at max quality the filters are created with -90/-75 dB stopband. It used to be -75dB for both. When I complained about that a few years ago, “Up” got bumped to -90dB, but IMHO this is not enough. As I wrote back then, I’d expect oversampling to use the same quality as a top-end audio interface as it should be the weak link in the audio-quality chain.

I ended up patching the Juce Oversampling to have another constructor that takes the stopband db values to apply and use -110dB for up&down stopband attenuation.

[lcapozzi]

Ivan suggested me to try using a different oversampler constructor and, then, add the stages:

oversampling.reset (new dsp::Oversampling<float> (2));
oversampling->addOversamplingStage(dsp::Oversampling<float>::filterHalfBandPolyphaseIIR, 0.05, -90.0, 0.05, -90.0);
oversampling->addOversamplingStage(dsp::Oversampling<float>::filterHalfBandPolyphaseIIR, 0.05, -90.0, 0.05, -90.0);

This helps a lot, since I now got the 16x performance using a 4x oversampler, but it doesn’t go better than that even with a transition band of 0.01 and -200dB of attenuation.
I got close to the competitor’s performance stacking stages up to 32x, but it’s overkill on the CPU.

[pflugshaupt]

What is your competitor’s product? It might do more than just oversampling to reduce aliasing.

[lcapozzi]

it’s an analog simulation of a distortion pedal. we get pretty much the same spectra (including aliasing) with no oversampling. It also offers FIR and IIR as oversampling options and I compared both. Later I’ll try without the Juce oversampler, using another class with a custom FIR and, as further test, with HIIR.

[kunitoki]

if you search for the steepest transition band and you can live with a maximally linear phase response and some ripples around the transition band, i had great results downsampling with a bessel filter.

[pflugshaupt]

It’s possible that -100 dB is the maximum achievable stopband using floats and the JUCE oversampler class. You could try running the oversampler using doubles. Of course that’s even slower, but maybe it allows you to go lower on the stopband. If I remember correctly the JUCE oversampler uses SampleType for the recursive coefficients (v1Up and v1Down)… which limits the achievable precision. Maybe this has improved in Juce6, but I haven’t checked yet.

I checked and it’s still the same:

   AudioBuffer<SampleType> v1Up, v1Down;

So the only way around it without patching (which I did) is to feed it doubles… Would be nice if there were two template parameters.

[kunitoki]

also, are you processing your filter with doubles? i had quality problems in the past with coefficients and intermediate calculations done with floats

[pflugshaupt]

The JUCE oversampling class always uses the SampleType for all filter calculations, so it’s likely all float.

[kunitoki]

it’s really only the audio buffers that should be floats, any manipulation of them that is not addition or subtraction should be done in double precision space then converting back to float before writing into the audio buffers the altered signal

[pflugshaupt]

Yes. I’ve had this discussion before here. The issue was performance from using double operations and compatibility with the juce SIMD types for multi-channel operation. So nothing got changed and I made a patched version for my own usage that uses double operations as well as doing the two parallel structures at the same time using SIMD.

Oversampling efficiency

I had another look and a good reason is only having to read samples from memory once instead of going through the buffer for each stage. However, it would be easily possible to just use one loop for both the direct and the delayed stages. NumStages is always even, so both loops iterate the same number of times. That might even give the compiler a chance to do that SIMD optimization for us as it’s two times the same independent code in a loop. Even better would be a template solution where num…

[DSP module discussion] New Oversampling class

I think big gains (x2) could be achieved by using the parallel property of the IIR multi-phase filters. It’s two independent filters in parallel outputting interleaved samples, so they can be calculated at the same time using SIMD. The FIR filter could also be done using SIMD and could scale even more than 2-fold as it’s parallel by design. This would all apply to single-channel oversampling and by extension also multi-channel. Of course, the internal processing loop is the most important thing…