High-pitched noise with RR group XFades with low buffer sizes

[tomekslesicki]

@Christoph-Hart sure, here are some bounces for you:

64 buffer.mp3
32 buffer.mp3
128 buffer.mp3
256 buffer.mp3

The glitch appears at the very start of the files. At 256, it's inaudible.

And some spectral views from RX:

Buffer 256:
https://imgur.com/OuIB6vk

Buffer at 32:
https://imgur.com/3SE8eea

The artifact appears where the crossfade takes place.

[Christoph Hart]

@tomekslesicki They sound exactly the same to me, but I'm not in my studio so I can't hear it on the speakers, just my AirPods.

Can you reproduce it with a less harmonic content? Usually these effects are best displayed with sine (or triangle) waves but the sawtooth kind of masks anything that might be going on.

Also does the problem go away when you increase the attack time?

[tomekslesicki]

@Christoph-Hart ok, try these instead, they should be more obvious. I replaced the sawtooth with a sample with less harmonics, and adjusted the xfade tables to showcase the problem in a more in-your-face way:

Test 2 buffer 64.mp3
Test 2 buffer 128.mp3
Test 2 buffer 256.mp3
Test 2 buffer 512.mp3
Test 2 buffer 1024.mp3

The problem is still there, even at 512 and 1024 when the modulation gets slower - listen to the entire files, they're not super long, and will hopefully give you a sense of what's going on.

The xfade tables are set like so:

Group 1:

Group 2:

Updated snippet:

HiseSnippet 1262.3oc4X0saaaCElJNLs1qMcsnWraFftXWjhTjZm37G1EyI9mFiZGaX4zkbUAiDsMWjIEnnbh6v.1iztZW28JrWg8Br2fMRIYaJG21Til.WTcgfN+Q9wy4vCOTM4LaruOiCLR2dnGFX7.n0PpnWwdHBETsDv3dvSqfbvfCG5g78wN.CiTuTIzH8xfvm+8mND4hn13Ir.fWyH13Zj9DwDtMK7JhqqZzZS5qoc9BUsYzhLWVfDHofYAdH6KPcwGiTpsDDXrRYGhfwsDHA1GXr7gLmgV8XWRiz+0Dex4tXEQNfkbfhXWg45nPrhKnXOhqSyQKXe.v.1bxxOUzx+ov5DGxX9SbCean.yIVn6OLVJI7Rk.d4zgWVM3MCHYnAokifzigV1bhmXhDEd9FXUp.y6frSFZhzEX72vhLoBTwF8QWfqvkDiMXscxl84lxWO6Gyj4EuvrYqxVVlE2z73FsK2IfZKHLpIidLSfaPW6YY90Loy7aYLmVTmNyTlZh4LWWLelhUwd9Gxv0nA8OGyet4.ja.drhRGRRuL786k0SBri7CZJxnUoDQCOL88kZ.hcdxuNoZIj.oBMw7j54g4BhBBFkvCj44QApzvRX+KDLOYl90hhx7GlSfKRjLoRsSJVfzGjHRpBWTehXn9NsOaYZ2TH9XXShvt2rw3Ry.iRO0sAFi2e9PX4Ncv1hI.bYXkSuc1LpO8eezz+DnkfiQ8IztVn9dxT7PLjAFSk6yQYRuabYxlbrKC4XQdqlZuqvgAReDOI2+nP3TcPeV.MwbEi7VXOLRHCyZ1b+BsZ8RNKvaZq.EBSJZykkoktB80XCJV5q00ETjy786HWNgikut1MC3cU9pIJ2BO.y8Sx63f9x3MkhcU65MLT6J8wp3KwtNRvIWoqc3rjsMJLF+mvbas4Fie1un70fFVux+s6Ml4fF0u5Hq80jeJduK1WStT8qzk6rU200kWkTqx5ZxK0X2ZqqI2dXcKc4mbxImoKW9pit7n0PtYuFhsoxY+xk6oYSqJm0VGSmKx6pi4F6NXnt7KK1XC84baWTEcLQpcUMc4Jejt7b+L9Lc4iWCwxiVCaFuFjmgGRu0Tz4mhd6on2YJ5cmPGk3VG4E0kxUpLrqcFwJ2ryHjiRSjL+RSyCIcGOCQb9HcSrxBW2DeAbLThFdROBiVDkiuLcfr7ljiBiOQd3ZGTfqXD2jkZqynLudLJwNYwDYwgtcwbcrOyEzABgrV1DNOsPKrKF4qUM7GJTiPwHdxZjeR9hbexM+My302Aifqo57AyubaeH0WMsO7gbQqF27fobF4hEvX3CfgkdMu10.uCKM7nH7cO3AGUxpUbpU32l2lEDJFvGjnesRXazvqwMY0ie+e9qBQbpIalwUWwijGgnWQIb3Fy3c7BVA9hDcMpv7TEhxWnrM61qJD7FlV7P8pPKfosqNBeQQgEw8Ugg+EU+2ifwIiKrNvUgw6MtycgsXAB4EeFc4Cn7FJVxakYi0umxRp69DQmUQq.gEl5DR7exmXg4FcoFkvbiDBrGMTx0S72g+IBiTXppI3vKf6NcEFe4c+TPR1f7cBJ6ir4r2XG8maTX89gbjnjF9y6RCqqnMyAB+aN5PsurE32XambntlgaNuFt07ZX940vsmWC2YdMb240v893FptgxAABV+n91.f5MKGk.ZTdbBXJv+Cr2bdeJ

It doesn't matter what is modulating the xfade - LFO, envelope and scriptnode modulators all create the same issue.

[Christoph Hart]

Hmm, I can't replicate it here, it sounds like this:

HISE_One_Second_Dump.wav

(it's with 64 samples buffer size, but it doesn't change with other settings). Does the sample rate have an effect on the artifacts? This doesn't sound like zipper noise of a poorly control rate but rather some resampling issue.

Can you upload a short file with raw PCM (not mp3), then I can look at the waveform to spot some irregularities (I don't trust the MP3 codec not to mess with the artifacts with their psychoacoustic compression techniques)?

[Christoph Hart]

nevermind, I followed my own advice and replaced the sawtooth with a slightly saturated sine and now I can hear it.

Sometimes I'm so smart it hurts... alright, now onto the debugging...

[Christoph Hart]

... And it's gone.

It was in fact an issue with a too low threshold (60dB) for detecting whether to use the full modulation signal or just a single value for performance reasons. I upped it up to -80dB and now it's basically inaudible.

Let me know if that problem persists with your real-world project, then I'll add a custom preprocessor where you can define a threshold for the detection - it's used in a few other places, just search the codebase for 0.001 and look for comparisons.

There was another related thread a few weeks ago about the AHDSR silence threshold so maybe it might be a good thing if this was customizable without hacking in the HISE Source code.

[tomekslesicki]

@Christoph-Hart thanks so much, I'm going to check this later today!

And I'm all-in for customizeable silence thresholds!!!

[tomekslesicki]

@Christoph-Hart I noticed you just added the HISE_SILENCE_THRESHOLD_DB preprocessor, thanks! :-) Could you please tell me about the value logic? For example, if I'll build HISE with:

HISE_SILENCE_THRESHOLD_DB=100

the threshold will be set at -100db, or should I rather build with

HISE_SILENCE_THRESHOLD_DB=-100

instead?

[d.healey]

[Christoph Hart]

This is in the comment of the preprocessor:

but you can override this (as a positive value, it will calculate the gain factor by taking the
number as negative dB value and convert it to a gain factor)

But it doesn't use this value for the crossfade detection (I've still hardcoded the -80dB) there, so you don't need to change this preprocessor to fix your issue.

Edit: Dave was faster :)

[tomekslesicki]

@Christoph-Hart @d-healey thank you!

I just tested the latest commit and it's indeed way better, but I'm still getting a bit of the buzz when the envelope gets to the curved part (so when the modulation slows down). Could you please bring it down a little bit more, or add the xfade threshold as a preprocessor so I can experiment with this myself?

[Christoph Hart]

@tomekslesicki you can just change the location I modified in the commit and use an even smaller number above zero, then let me know what you end up with :)

[tomekslesicki]

@Christoph-Hart well, that was a logical answer :D I built a couple of versions with different values and 0.00000000001f works prefect for all buffer sizes.

[d.healey]

@tomekslesicki said in High-pitched noise with RR group XFades with low buffer sizes:

0.00000000001f

That's some precision!

[Christoph Hart]

0.00000000001f

haha this is basically zero with the single precision resolution of seven digits... You're effectively just deactivating the logic that will save you CPU cycles when there is nothing going on in the modulation signal.

I guess I'll rather make a preprocessor like HISE_ENABLE_CROSSFADE_MODULATION_THRESHOLD and if that is set to true, it uses the -80dB threshold that gets rid of most artifacts and if that's not enough for your particular project you can disable it entirely by setting this to zero.

[tomekslesicki]

@Christoph-Hart sounds like a good plan! ;-) By setting it to 0, you mean something like this?

HISE_ENABLE_CROSSFADE_MODULATION_THRESHOLD=0

[Christoph Hart]

@tomekslesicki yes. Also you then can just leave it as default in HISE and just add that to your project definitions (if you can live with the low artifacts at -80dB during development), this way you don't have to edit the source code at all.

[tomekslesicki]

@Christoph-Hart epic, thank you!

[tomekslesicki]

@Christoph-Hart we don't have this HISE_ENABLE_CROSSFADE_MODULATION_THRESHOLD yet, right?

[Christoph Hart]

@tomekslesicki ah yes my goldfish brain with its limited attention span moved on to the next fancy thing…