Using Double instead of Float increase noise?

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

JCJR wrote:
Nowhk wrote:
Miles1981 wrote:Just remove the function altogether, it won't be that slower
And I swap that function with... what? How do I tell the algorithm to denormalize under.... -60dbfs? (which is why the function is made right? cut under a fixed SNR...)
Yeah, try without the function and MyStran's advice on telling the compiler to tell the computer to ignore denormals.
Why are you capitalizing the 'S' in my nick name, that makes no sense?

Post

JCJR wrote:Yeah, try without the function and MyStran's advice on telling the compiler to tell the computer to ignore denormals.
I've just removed the denormal function without using mystran's advice (which, honestly, I don't have understand what he suggested), and the noisy is "magically" vanished (using doubles) :o
JCJR wrote:The code isn't to cut under a fixed signal to noise ratio
So, what's the meaning of denormal? Why he use it in his code? And why it works to me (on both SaviHost and FL Studio) without it?

I thought It act as "bottom" threshold to remove the huge (more) noise introduced by doubles (summing each other on processing feed in the comb filter), due to its higher SNR... but I think don't get it at all.

Can you help me to cover this part?

Post

Denormals are simply very small (close to zero) numbers which on some CPUs lead to huge increase of calculation time.

The code to detect these numbers uses a bitmask (for performance), and this code simply does not work for doubles.

https://en.wikipedia.org/wiki/Denormal_number
Last edited by Chris-S on Thu Aug 25, 2016 8:39 am, edited 1 time in total.

Post

Compiling with SSE2 will remove the problem without extraneous instructions, but you must set the SSE control word with the correct flags. Take a few minutes to poke around the x86intrin.h file in your compiler's include directory.

http://softpixel.com/~cwright/programming/simd/sse.php

Post

Chris-S wrote:Denormals are simply very small (close to zero) numbers which on some CPUs lead to huge increase of calculation time.
So this has nothing to do with SNR/noise produced on computing/processing filters/feedback/reverb with small values? It's just a matter of performance?
camsr wrote:Compiling with SSE2 will remove the problem without extraneous instructions, but you must set the SSE control word with the correct flags. Take a few minutes to poke around the x86intrin.h file in your compiler's include directory.

http://softpixel.com/~cwright/programming/simd/sse.php
I didn't touch any SSE control word, and it seems to have remove it (I don't hear any noise or problem on performance). Is it that I'm lucky and my CPU ignore them automatically?

Post

Yes, your compiler and/or DAW may do this automatically or your CPU is not affected by denormals.

Beside of setting the SSE flag there are other methods like mixing in a very low (-200 db) noise to keep the numbers "big" enough. :wink:

Post

Chris-S wrote:Yes, your compiler and/or DAW may do this automatically or your CPU is not affected by denormals.
I see, thanks!
Chris-S wrote:Beside of setting the SSE flag there are other methods like mixing in a very low (-200 db) noise to keep the numbers "big" enough. :wink:
So this really means that denormals "gate/function" is not at all to reduce noise (if I add noise to prevent denormal) :D Right?

Post

Correct.

Post

Still not sure about this :) Sorry but I'd like to investigate.

Well, I've read this nice document about Denormal: http://www.musicdsp.org/files/denormal.pdf
At some point it talks about 3.2 Preventing denormalization, suggesting a trick to avoid denormal numbers.

For what I see: add a small noise and later remove it, so very low values will not processed as "denormal". So with a friend of mine, we had done some discussions and experiments.

This is a code provided from him, which show how (on a basic IIR 1-pole LP filter) using this "noise-tricks" the SNR doesn't go under -100 DBFS (instead of 385 DBFS) after 400 steps: http://coliru.stacked-crooked.com/a/e0f7c0cfbfa7ec91

As he said, avoid denormal numbers it's not only for don't stress CPU: the SNR is smaller...

Post

I would need to do a test on a dirac signal, but for now, the difference between with the flush and without is not noticeable. Will try to do more tests.

Post

Nowhk wrote: So this has nothing to do with SNR/noise produced on computing/processing filters/feedback/reverb with small values? It's just a matter of performance?
That is true but in the old days of single-core pentiums, "just a matter of performance" might be like describing a hurricane as "just a big wind." :) A single plugin with a denormal problem could make your computer about as useful as a doorstop until you reboot.

If you could manage to get the "slow motion" sequencer to recognize a stop command, perhaps could stop playback, remove the bad plugin and continue operation. But sometimes the ultra-slow processing would blue-screen the asio driver or get so "compute-bound" that you could not get the sequencer to stop the ultra-slow-motion playback. If you couldn't make the sequencer stop, there was no choice but to hard-reset. Or alternately wait an hour or two until the sequencer finally finishes painfully playing a three minute song. :)

I added low-level noise in plugin hosting to help avoid denormal-bug plugins. Sometimes just a slight DC offset is enough to avoid denormals in plugins which have that bug. It depends on the nature of what the plugin is doing, exactly what process leads to the incredibly tiny numbers. A DC offset might prevent a denormal bug in one plugin, but not another. There are probably cases where even noise would not prevent denormals in buggy plugins.

Denormals are not the only weird numbers you can get returned from a buggy plugin (or make yerself with yer own buggy code). I eventually added an asm tight loop to scan plugin returned buffers to remove all possible weird numbers. As self-protection and to prevent errors propagating from one plugin to the next plugin in a chain.

Found this article describing the ways good floats can go bad-- https://www.cs.uaf.edu/2011/fall/cs301/ ... loats.html

That is all old history. Listen to someone who knows how it works nowadays to decide how to do your code.

Post

JCJR wrote: Denormals are not the only weird numbers you can get returned from a buggy plugin (or make yerself with yer own buggy code). I eventually added an asm tight loop to scan plugin returned buffers to remove all possible weird numbers. As self-protection and to prevent errors propagating from one plugin to the next plugin in a chain.
I actually do this in all my plugins (except I don't worry about denormals 'cos I just let the CPU flush those to zero): any audio that I get from the host first goes through a function that replaces any infinities with finite values and any NaNs with zero. I do this mostly in order to protect myself from problems with my own prototypes upstream, but it's there in all my public versions too, 'cos why not. :)

Post

What I still don't understand is why (from this topic) it appears that denormal problems are all related about performance (yeah, more noticeable in the "old days"), and nobody talk about the huge increment of SNR that they may introduce; maybe because (for experts like you) that's just expected?

Take the filter in the example above (from the link of my friend): processing samples with or without denormals is not a matter of performance there (the code is faster), but looking at the SNR, the increment of noise floor is so huge.

But yeah, maybe for you that's just obvious, which doesn't deserve to be discussed :hihi:
mystran wrote:except I don't worry about denormals 'cos I just let the CPU flush those to zero
You tell this from the code, right? I found this for UWP:

Code: Select all

extern "C" void __CRTDECL _initialize_denormal_control()
{
    _controlfp_s(nullptr, _DN_FLUSH, _MCW_DN);
}

Post

You mean decrease in SNR? If the noise floor increases, then SNR diminishes.
I don't think that they add that much noise. We are talking about values that are small for floats, ridiculously small for doubles compared to the range of values audio has.
The filter from your friend doesn't FTZ denormals, it adds a constant value that is far bigger than denormal numbers, at 10-6. This gives indeed a SNR that is quite small, higher than the 120dB than you could achive (in the link he shows NSR and not SNR). Now use a real denormal, or just above, this would give a completely different picture.

Post

Miles1981 wrote:You mean decrease in SNR? If the noise floor increases, then SNR diminishes.
Oh yeah, my fault! Sorry!
Miles1981 wrote:I don't think that they add that much noise. We are talking about values that are small for floats, ridiculously small for doubles compared to the range of values audio has.
So if I temporarily ignore the fact that denormal numbers will stress the CPU (and maybe crash my PC) and I keep them in my audio process (such as the reverb of this thread, which constantly feed/sum them recursively), nevertheless I won't notice any bad artefacts on keeping them during all steps of my audio generation? Shouldn't I keep "as necessary signal as I can" as rule of thumb? Or are they so insignificants that I really can ignore them?

Or maybe you are just saying that the signal between last normals and the last denormals (1.18 × 10E-38 - e 1.4 × 10E-45) is nothing compared to the signal between a fixed (usual) threshold/bit depth (-120DBFS) to last normal (1.0 * 10E-6 - 1.18 × 10E-38).
I mean: if I don't fix any threshold, the values above denormal values up to -120 (where usually you set the range/bit depth) make irrelevant the denormals ones. The fact is that I don't have set that threshold /my bit depth) in the reverb. Thus, even if i FTZ denormals, there is still lot of noise that I'm processing...
Miles1981 wrote: This gives indeed a SNR that is quite small, higher than the 120dB than you could achive
What do you mean with "SNR quite small"? I think he is limiting "Bit Depth Range" here, from max deep (-385.32 DBFS) to 0.00001 (his -100 DBFS). But the SNR (as "ratio) is not quite small (decreased) because noise floor is increasing :o

They are two differents (but relateds) things I guess? Maybe I'm interpreting bad your words :)

Note apart: thanks for your time! You are kind!

Post Reply

Return to “DSP and Plugin Development”