HIFix - open-source Hearing Impairment Fix

[steph_tsf]

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.

Ough! Isn't this going to exacerbate the denorm issue?

There are a couple of ways to deal with denormals. One can 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.

Indeed, the RMS detector that I found on the forum, was plagued by some mysterious illness. It lost precision below -40 dBFS, pretending that the input was always more than -48 dBFS. My application demands to remain precise, till -70 dBFS. I wrongly concluded that a RMS detector was due to remain plagued by some internal noise or offset, despite the 190 dB (32 bit floating point) dynamic. I took my can opener, and opened the DSP Edit module. Surprisingly simple.

Code: Select all

monoin x;
monoin a;
monoin y1;
monoout y;
//RMS
y=a*x+(1-a)*y1*y1+0.00000001;

Such code doesn't include the square root block that's following, that's establishing the required feedback. Consequently, such code is only dealing with the RMS detector time constant. The cure was simple. Instead of specifying a 0.00000001 offset, I specified a 0.00000000001 offset. Now the RMS detector remains accurate, till approx -90 dBFS. I don't know is such mod, will cause denorms. How to test this? Wiring a -0 dB to - 200 dB attenuation at the input, opening the Windows task manager, and watching the "performance tab" ? Sounds a little bit crude. Is there a better way?

Any suggestion welcome

[trogluddite]

Ough! Isn't this going to exacerbate the denorm issue?

It's one of those problems where there isn't an ideal solution which will fit every case. When zero-ing the value renders a feedback loop completely inactive, it will work (e.g. a simple delay with feedback), as zero is not treated as denormal. However, where other values are accumulated in the code, it is less likely to be effective. Wherever and however you deal with denormals, there's always the possibility that some later calculation brings the value below that limit (or marginally above zero) again, and as you've found with the "DC offset" technique, one always has to be vigilant for unintended side-effects.

Is there a better way?

You might find this module from MyCo useful - it allows the values from any blue stream to be inspected, including counts of the number of denormals, NaN, infinity, etc. discovered...

streaminspector2.fsm

(10.76 KiB) Downloaded 919 times

A little deduction may still be needed where denormals might occur within intermediate calculations inside a DSP/ASM block, coupled with the occasional added "debugging streamout" - but it's saved me many hours searching for otherwise unexplained CPU peaks!

[trogluddite]

Ah, sorry, I was a bit hasty replying; tidying up the "404" posts led me to skip reading your earlier content!

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.

Yes, I've noted the same thing in some of k_brown's schematics where he's used some of Martin's code. As you say it's related to Ruby initialisation (and possibly differing FS versions?). It happens when the Ruby isn't coded using explicit "init" and "event" methods. The problem goes away as soon as a new 'green' value arrives at the affected input, so a workaround is to attach an "AfterLoad" primitive in parallel with the input connector to cause an explicit update at startup (not ideal, but it saves having to rewrite the Ruby code).

output(@in.map{ |x| x.nan? ? 0 : x })

The "map" creates a new Array, where every element in the input array is transformed by the code block in curly brackets (essentially an anonymous function passed each array element in turn as |x|). The block is using what's known as the "ternary operator", an abbreviated form of "if..then..else" - here; "[if] x is a NaN [then ("?")] return zero [else (":")] return x". The first '?' is part of the method name "nan?". Ruby allows method names to end with '?' or '!', and by convention, predicate methods which always return true or false usually end with '?' (though the methods added by FlowStone generally ignore this convention!)

Is there a built-in "square root" component operating in "green"?

There never has been, to my knowledge - I always did think it was a bit of a strange oversight!

isn't there a "denormal disable" bit that Flowstone could activate?

As discussed a few posts up by MichaelBenjamin, there is; but unfortunately it works at a rather too coarse level to be guaranteed safe to use; and the assembler doesn't currently recognise the opcode to change the setting.

Unfortunately, they rushed into adding the "denorm" feature

Whatever one might think of the decision, it was anything but rushed. Historically, arguments about denormals led to the IEEE standard taking much longer to negotiate than it might otherwise have done. We're stuck with many historical legacies which don't suit DSP - such as "bankers rounding" being the default rounding mode because IBM's customers were primarily people wanting to do calculations involving money (which rather ironically, they rarely use native FPU maths for these days, because it won't round decimal currency denominations as they would prefer!)

Likewise with support for complex numbers and rationals. They can be supported by explicitly coding them (Ruby has Classes which model both), as any mathematic rules can be implemented from first principles once the basic axioms are in place (q.v. "Turing Completeness"). Many hardware implementers would argue that the x86 instruction set is already too bloated and that smaller instruction sets with faster throughput are more optimal (e.g. RISC architectures). It is a debate which I doubt will ever reach any conclusion which satisfies all parties!

The FPU should provide the bolts and the nuts that the 40-bit software is requiring for executing as fast as possible. Is it the case? I want to know

You have to be careful here, as "FPU" has a very specific meaning in the context of x86. The FPU is a high-precision floating-point calculator which does use more than 32-bits for intermediate values to guarantee that the result is always accurate to within the smallest bit of precision. However, it can only perform one calculation at a time, and values have to be passed back and forth via a special stack structure. If you see instructions beginning with the letter "f" in assembly code, those are usually FPU instructions.

However, most stream code uses the SSE instruction set, which allows multiple calculations simultaneously, and doesn't need values passing in any special way. These are very much faster, but the range of available maths functions is far smaller, and there are a few which don't operate at full precision (hence my previous confusion about the precision of 'sqrtps').

This separation is yet another historical legacy - floating point maths was an optional extra for the earliest PC's, so was implemented on a separate chip, and SSE was bolted on much later to help support multimedia audio and graphics (originally called "MMX" - multi-media extension). Neither were added with complex DSP in mind, as you will no doubt have guessed!

By the way, I don't know how they coded "NaN"

Part of the float value itself - by setting the exponent to a sentinel value (infinities work by the same principle).

How do you this in fixed point? This is complicated

As someone who has previously worked on a fixed-point FFT algorithm for embedded microcontrollers, I heartily agree! (and I strongly suspect that a certain Mr. deraudrl might do too!)

[Duckett]

I was just remembering the other day how massive the RISC hype train was in the early-mid 90s; AIM and all the trade mags were all about "CISC is dead, long live RISC" with PowerPC, waxing rhapsodically about what a game-changer it was- and yet, despite all the marketing, RISC never really found a home in desktop/laptops, and certainly couldn't live up to all the marketing build-up. Seems like RISC-V is the only "practical" RISC ISA around these days.

But I digress; while I'm no coder, I still appreciate discussions like these, as they give me more insight into where FS's strengths and weaknesses lay, and therefore a better picture of where ideas will end up in the "Pointless Waste of Time vs. Let's Explore More" table

[trogluddite]

waxing rhapsodically about what a game-changer it was- and yet, despite all the marketing, RISC never really found a home in desktop/laptops

Or we might say that they didn't see the game's goalposts being changed so radically by small-form-factor devices. RISC is by far the most common contemporary architecture when the ubiquity of ARM-based smart-phones/tablets/etc. is accounted for. Not that market forces ever showed any respect for technical superiority, of course!

[MichaelBenjamin]

.

[trogluddite]

Yes, fair comment, Michael - it's certainly not as "reduced" as the original concept!

[MichaelBenjamin]

.

[MichaelBenjamin]

.

[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).