Convolution gain louder at higher sample rates

Christoph Hart

The onInit callback will be executed before the samplerate is known in a plugin so you need to make sure to defer that - you're safest bet would be a script FX and its preparedToPlay callback because this is where you usually setup the processing stuff.

But just out of curiosity because your numbers differ vastly from my ones: what did you measure for the file you've uploaded? I am still not sure if this is a constant gain factor and how much does it depend on the impulse response type.

Dan Korneff

@Christoph-Hart I'll measure those impulses asap

Dan Korneff

for the file I uploaded
44 = -18
48 = -17.6
88 = -14.9
96 = -12.6
174 = -11.7
192 = -11.9

Dan Korneff

I'm just noticing that the first IR I uploaded was a stereo file, and the rest were mono. That appears to make a difference on the output level as well.

Christoph Hart

Yeah sure, let's add that to the number of weird reasons why the gain goes up. What else? The length of the filename? :)

Dan Korneff

@Christoph-Hart

mwplugs

convolution is producing a distorted digital noise at sample rates 44.1 and 48khz anything above the behave perfect. but with every one tested there is a distortion below 88.2

Dan Korneff

@mwplugs I'm about to add convolution to a project. I'll report what happens on my end.

mwplugs

@dustbro ok yeah i cant figure it out for the life of me

Dan Korneff

@Christoph-Hart I could use a little help getting Engine.getSampleRate() to work properly.
I would like to use the sample rate as a variable to compensate for the gain difference with different sample rates.
I've added a global variable with Engine.getSampleRate() to the preparedToPlay callback, which works in HISE, but the exported plugin shows "undefined" for the sample rate.

here's a snippit:

HiseSnippet 1224.3oc0X8+SabCE2GvMQRajZq1e.V7SAsD5EZfRWU0nDftnUfnFFqSUnNm6bRrvw9zYGFYUU6Os8ezz9OX6YeG4tKbvXYZnQ9g.98M+487yedF5DI8oJkLB4T53IgTjyCc6NQnG1ZHgIPs2E47DWEYTHmhiHZJVSUZzNSBIJEM.43r3aL14TZIj8ye7M6P3DgOMUDBchj4SeKaDSmJsy1eGiy2mDPOlMJi0M2tsuTzRxkiALsnqGJj3eFY.8PhwrEbQNewdALsLpqFviBrYGYvjtCk+rH19SXJVON0rnApKDnXwnVCY7fNWluJDxYoNoY+hwY+W5d.KfMUdZU3QVE3TOxVCbVHOjVJGjZbcPZeIOvDfqAdNYf2Rwv6wtc8iXg5TMFr8.21BMMpOAJ6YgUrsnE90EcaIAKD50FQNiteDrXpGU2zyqFdCOuUeYkxUJCEekFeNIB20dp+NHidKoGkieE9xfLfpaIGEJEvhpqLicqXhSZTLsGFioBEQyjBHL19KSP1qeepODgYsYkXnLSfWSQAa0zKzqTCmrqXi1uFuB9qveqToS8X0Whe5SwfGXtE7ZINSW70lnLPzqvenYyFPQo4Vdv2as05v2uXSyu234a1z7iW.h7N0tEDNGGJU1y2ragJ+djM8NgvGSUl8wqV8F0puds5OqV8l0puwoSQshYiz.nxXvtdHSAwA7yD19xHbUEFTkG5qVo7mpTFCeLa4AvQ83v1h.5ElhdNKWiYDeT+pET0fCFrUMV1GODzmuxYBe72ydrYNfdsVGw5MVSqdEsFA0JnP7gL.8zUutJfM4MHJKYjElUJ+YSQAJKiE91VLo3Poldjn5pk+T4Rk+bY7rp52uPclF7HImSiJTsgoJ5lbrpX7ndznZwncpgv0277CO31wO3GeeKigRQaASeDTAiWmxfXzEm0Wp0CMMYyJJMGyJ0lZEXVpnqRPgR3Cfe66auKQSLbVIx.6BoQZlIac1kdNL.HlAqj6tT0YZYn01DRDjiq1psRB+l8BOhEXY7xSCftHcXwnsmjt3G21vMXnvywMXuECyatBWJvnKCFyI57z7l1zDEvYaN9TCmoPwzSxNu6e.2uWgb+MJpzdKg6ic6vz9CKFuKT.dgin+qwaxjzJtwz6ofcI28e+cvXyEtZsqbRaEr+Ff7vjk38eeihFX576toWtCingjH5wxNbxjppoMi0v83R+y5x9k3K5C3xdD9Lig.h28DCXBpYbWp3plAbkfqJJImtVXDyLG8JdVzTsb7NgwI5NFbT0eHQHnb07PO4l+bX4a24PdxH3gZYqTobTYQ4Mxv72zh8N4XMSL3.BLgA3.bOb7ntviD8osRxbPlyBFZo30dl0lN9tTQfcweBeRT1vr1IQYiKU9ujQK6sfkm9ZZ6br2j9Z5YGLdcul9m.1keaWJTKyd88GXA5gYI8J381sEmCHsijShl8x+h2zamaLmuc9lYnLoD9dCi5Sbsk76S.11Rb+AvOxsC4+CMD2E7I2E6wHhej7i9wrolqlKak.4sv9mLWx8.yZbCjk1G7y0aMOzH3Om8i99lwx0g5Sw9r9b3yylCeZNG9rwb3ylygOOeN7YqazGy+IgWOVKGE2+CB5rmcZiiydBBzIauJf9KvoIPOm

Christoph Hart

You're declaring the global variable in the prepareCallback itself (I wasn't aware that this is possible, might have to add a safe check to prevent this at some point).

This means that the variable will be initialised long after the interface script has run, so undefined is exactly what's happening...

BTW, the safest way to use global variables is to define them in the first script (most likely the interface script) and also tuck them behind a condition so that it just gets initialised if it doesn't exist:

if(!isDefined(myGlobalVariable))
{
   global myVariable = 90;
}

If you don't do this, the variable will get reinitialised everytime you compile the interface script which is not a problem in your case, but might lead to annoying issues when using more complex data (because the other scripts might use a reference to the old object).

Dan Korneff

@Christoph-Hart Thanks so much for this! I think I have it (mostly) working.
Any words of advice on how to deal with a user changing sample rates while the plugin is loaded?
I tried this in the preparedToPlay callback with no luck

if (HostSampleRate != Engine.getSampleRate())
{
     ..... some function to update HostSampleRate
}

lalalandsynth

@dustbro said in Convolution gain louder at higher sample rates:

uch for this! I think I have it (mostly) working.
Any words of advice on how to deal with a user changing sample rates while the plugin is loaded?
I tried this in the preparedToPlay callback with no luck

Was this ever solved or do I need to monitor the sample rates and change gain accordingly ?

lalalandsynth

@lalalandsynth ittybittybump. :)

Dan Korneff

@lalalandsynth I believe you still have to self monitor these changes

Christoph Hart

Actually I'm not sure whether this is a bug in the convolution engine or a physical /mathematical law that you need to counteract manually. I'd love to encorporate a automatic fix for this into the convolution module directly, but it's not so easy, so maybe something can help me out here.

Let's assume we have a impulse response at 48 kHz with a single dirac at 0dB at sample position 512. And we're convoluting a signal with the same samplerate, then it would be a simple static delay of 512 samples without modification of the gain. Now If we switch to 96kHz, the impulse response needs to be resampled to match the 96kHz signal input. However this means that the upsampling will duplicate the dirac impulse (so that in the 96k response, we'll have a dirac at sampleposition 1024 and 1025, both at 0dB. If we now convolute the 96k signal, we'll get two delays short after each other which basically causes a +6db gain.

In this simple example, the solution would be a 6dB attenuation when we double the samplerate (+12db if we quadruple it, etc), but this is only working for this extremely simple test case - as soon as you have a "real" impulse response the upsampling will not be in this linear relation.

I'm not sure how other convolution reverbs take this into account (or if they don't), so if anybody has a clue about this, let me know.

d.healey

@Christoph-Hart Might be of interest - https://github.com/juce-framework/JUCE/commit/68d30f9c8d8571acf43a39caffc7d5b64ed9f253

And here's the forum post - https://forum.juce.com/t/dsp-convolution-changing-level-depending-on-the-host-sample-rate/

Christoph Hart

@d-healey Well the comment below the commit is correct, the problem is that you can't expect the linearity between resample factor and output gain - you even can't expect the gain change to be the same for each input signal, so it's a highly imprecise thing after all.

lalalandsynth

@christoph-hart I guess it would be helpful to have an approximation at least, I guess not many users are switching sample rates mid project?

ustk

Or getting a tool that tests different samplerates for an impulse and spits out a compensation table (why not an API we can directly use in script? but execution time might be a problem, or not with the new background thread...)

As @Christoph-Hart said it also depends on the input, but this is a lesser problem since users need to compensate for the signal they put in (as it's always been the case in any audio processing)

Convolution gain louder at higher sample rates

15

1.7k

11.8k

103.0k