HIFix - open-source Hearing Impairment Fix

[steph_tsf]

Thanks Martin for suggesting the two CPU% decrease tweaks. Regarding the block diagram, are people going to be shocked, by the fact that I am nesting the 0 dB ... 60 dB gain control inside the compressor-limiter structure? Won't they complain that doing so, one is wasting 60 dB of precision? Are people fully trusting the 32-bit floating point resolution? Will they say that the compressor stage is requiring a dedicated, independent RMS detector?

[trogluddite]

Regarding the block diagram, are people going to be shocked, by the fact that I am nesting the 0 dB ... 60 dB gain control inside the compressor-limiter structure? Won't they complain that doing so, one is wasting 60 dB of precision?

In this case, where both compressor and limiter are inherent requirements of your concept, I would say the opposite - it represents good design, as you stay within the decibel domain for all series components which require it. As a general rule of thumb, round-off errors are minimised when operands are of a similar order of magnitude, so I would be very surprised if any precision has really been "wasted" in the overall scheme compared with alternative implementations.

Are people fully trusting the 32-bit floating point resolution?

Most seem to trust floats right up until the point where they come complaining on the forum that their computer broke the laws of mathematics because they don't yet understand how IEEE 754 floating point representation works!

[steph_tsf]

...because they don't yet understand how IEEE 754 floating point representation works

Can you please describe a few juicy cases, or symptomatic cases, as I fear that it'll take some time before I fully understand how IEEE 754 floating point is dealing with denorm, nan, nil, invalid, etc.

[steph_tsf]

Post erased, because of the absence on Flowstone, of a x86 SSE Mono4 64-tap FIR filter component, and a x86 SSE 64-tap Widrow-Hoff LMS Machinery.

There is no use in mystifying people with various unproven unfinished "alternatives" that are requiring a "double" floating point precision, a FFT then inverse FFT process, a PhD in complex plane navigation, etc.

The HIFix (open-source Hearing Impairment Fix) must remain a back-envelope sketch, a kind of sandbox, an idea shaker, that's relying on mainstream stuff.

In case there are fatal unavoidable limitations within Flowstone, preventing a 64-tap FIR filter and a direct derivative like the Widrow-Hoff LMS Machinery to become commodities, think about relying on ASIO, seen as synchronous FIR filter provider, eventually hardware assisted by a ASIO-USB2 software driver and ASIO-USB2 hardware dongle that's embedding a STM32H747 (USB High Speed 480 Mbit/s, grabbing audio from USB2, returning the processed audio to USB2), eventually helped by one or two more STM32H747 (grabbing audio using SAI, processing audio full steam, returning the processed audio to SAI).

[trogluddite]

Can you please describe a few juicy cases, or symptomatic cases, as I fear that it'll take some time before I fully understand how IEEE 754 floating point is dealing with denorm, nan, nil, invalid, etc.

Phew - a big subject indeed! So firstly, a couple of useful links...

For a gentle introduction to floating point representation, this website is a good place to start, with links to more advanced concepts for those who need them. For exhaustive (and possibly exhausting!) detail, including mathematical proofs, I suggest this extremely comprehensive article.

"Nil" we can disregard. It is an unrelated concept which, in the context of FS, only applies to Ruby (it has no fixed meaning; "unassigned variable", "no search result found", "data is unchanged", "feature disabled", etc. as indicated by documentation). As a brief summary of the others...

- Infinities are designed to work as closely as possible to mathematical theory - they are not a kind of error condition, as some people seem to treat them. If an operation on infinity is theoretically defined then, within the bounds of precision, that will be the result; e.g. the comparison (finite < infinity) will return true, and (nonzero_finite / infinity) will return zero (there is no representation for infinitesimals).

- NaN ("Not a Number"; or sometimes '#IND' = "indeterminate") means that there is no theoretically defined result for the operation (assuming only real numbers, of course). NaNs propagate - that is, any operation on a NaN will always return another NaN. The idea is that testing for NaN after every single operation would waste CPU resources; propagation ensures that we can rely on being able to test for NaN only at the end of a sequence of operations. The obvious worst case is that a NaN within a feedback loop will propagate forever unless trapped.

- Denormal numbers are a direct consequence of the floating-point representation. Floats are stored as (value * 2^exponent). By shifting the exponent, 'value' can be made to always have a most-significant bit that is one; so an extra bit of precision at the least-significant end is made available by assuming MSB = 1 and not storing it - this is "normalisation". However, this would limit the smallest number that can be represented when the exponent reaches the lowest available value. In this case the MSB = 1 restriction is relaxed, at the cost of greater CPU power being required to perform calculations on the "denormal". The lowest "normal" exponent is -126 for 32-bit floats, so these values are extremely small!

Denormals are such small numbers that in many cases we do not need to worry too much about them - for example; even a "professional" 24-bit soundcard cannot possibly give us such an input value. However, any process with exponential decay might easily produce them, especially if an input is not always present. For example; if the "send" to an echo effect with feedback or an IIR filter is turned off, many people are rather surprised to find that "no signal" suddenly consumes vastly more CPU power. Internally, there is a "signal", of course, but denormals are so small that no audio meter will show them, and they are most certainly not audible!

There are a couple of ways to deal with denormals. Firstly, we could test whether a number is within that range and truncate it to zero. Alternatively, a very small amount of noise could be added to the signal to ensure that following calculations rarely enter the denormal range (or the noise floor of analogue input components might provide this free-of-charge!) A variation on the second method is to add and then subtract a small DC offset, to push the exponent beyond the denormal range and deliberately force rounding - this is often the most economical method, and can be seen in a few of the modules you've used in your filter/compressor schemes.

[RJHollins]

a curious question ...

There has been an ongoing discussion for conversion of, say, 32fp to Integer [24, 16 bit].

So, first thing .... the actual Audio Stream from FS ... is it 32fp or something else.

That answer may lead to followup questions [Dithering].

[trogluddite]

the actual Audio Stream from FS ... is it 32fp or something else

Yes, streams are floating-point throughout. The native format of the soundcard may not be, but the ASIO/DS components handle whatever conversion is needed implicity. Also, the VST API only defines 'sample32' (single-precision float) and 'sample64' (double-precision float) types for audio samples, so similar applies to exported plugins.

That answer may lead to followup questions [Dithering]

Let's see how good my mind-reading powers are!

32-bit floats have 24 bits of precision in the mantissa (including the bit assumed by "normalising"), so they are able to exactly represent any <=24-bit integer value (beyond that, not every integer can be represented; adjacent values will be separated by increasing powers of two) - or some other linear scaling with that many or fewer "steps". So, in principle, dithering to lower bit-depths can be coded using rounded floats that will convert exactly to the required integers. I'm not quite sure how sign would be handled in practice though - there's always one fewer negative values available than positive for signed integers (e.g. the -63..64 range sometimes seen for MIDI parameters) - an even number of integer values can't have zero exactly in the middle!

[MichaelBenjamin]

.

[trogluddite]

i wonder why this isn't set in synthmaker/flowstone as default flag

There is a caveat, though. The flags register is per-thread; and for a VST export, it's the DAW which creates the threads, which may include sharing a thread with other plugins and/or DAW processing. So there's no guarantee that some other code doesn't rely on the flags having their default values, nor any guarantee that the flags will stay as we set them. Would it do any harm? I think you're right that in the vast majority of cases it's very unlikely - but, strictly speaking, it requires entering the "undefined behaviour" zone in the case of plugins.

I remember that many years ago, there was a similar debate on the SM forum about whether we could use the flags to avoid all the shennanigans with the default "bankers rounding" mode - simplifying sample index and interpolation code by making truncation the default rounding mode. Likewise, the conclusion was that assuming the system defaults was safer than risking the chance of breaking unknown code elsewhere, or our code being broken by a reset-to-defaults.

[steph_tsf]

- "Nil" we can disregard ... in the context of FS, only applies to Ruby.

Thanks for clarifying. I have many FS RubyEdit modules, turning red upon starting, complaining about "nil", then magically becoming healthy after say one second. Now I know that such symptom is probably not related to IEEE 754. Now I know that such symptom is probably caused by improper initialization or missing initialization.

- Infinities are not a kind of error condition, as some people seem to treat them knowing that (nonzero_finite / infinity) will return zero.

Quite sympathetic, however triggering a denorm, I guess.

- NaN ("Not a Number"; or sometimes '#IND' = "indeterminate") means that there is no theoretically defined result for the operation (assuming only real numbers, of course). NaNs propagate.

Years ago, MyCo added a NaN eradication Ruby CodeEdit module into my dual-channel FFT analyzer. Such module remains cryptic for me. It does "output(@in.map{ |x| x.nan? ? 0 : x })". By the way, I'll check what's happening when computing the square root of a negative number in x86 SSE Assembler, in DSP Code Component, in Ruby ... and in "green" also. Is there a built-in "square root" component operating in "green"?

- Normalization. One extra bit of precision at the least-significant end is made available by assuming MSB = 1 and not storing it. When the exponent reaches the lowest available value, the MSB = 1 restriction is relaxed, at the cost of greater CPU power being required to perform calculations on the "denormal".

In audio, like in all applications I know, there is no need to distinguish between +/- 0.xxxxxx e-127 values and zero. In silicon, isn't there a "denormal disable" bit that Flowstone could activate?

Have a nice day.