HIFix - open-source Hearing Impairment Fix

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

[martinvicanek]

For Linear Phase Linkwitz Riley I could offer this: https://vicanek.de/articles/ReverseIIR.pdf

For a 1024 tap FIR I would recomend FFT else CPU will be prohibitive. Something like this: viewtopic.php?f=4&t=13137&p=44319

[steph_tsf]

What if opting for a phase-linear 6-band splitter, costing almost the same CPU% than a 4th-order Linkwitz-Riley one (that's not phase-linear)?

See it here:

Bandsplitter - Lipshitz-Vanderkooy - 6 bands (bandpass) (oversized delays).fsm

(48.52 KiB) Downloaded 867 times

Bandsplitter - Lipshitz-Vanderkooy - 6 bands (bandpass) (650 pix).jpg (67.32 KiB) Viewed 10402 times

Have a nice day

[steph_tsf]

What if opting for a compressor-limiter, per channel, that's embedding the channel gain control?

hearing aid RMS det comp gain lim.fsm

(18.05 KiB) Downloaded 875 times

hearing aid RMS det comp gain lim.jpg (650 pix).jpg (56.34 KiB) Viewed 10402 times

Have a nice day

[steph_tsf]

I understand the audiophile preoccupation of managing the compressor-limiter side-chain in dB domain instead of in LINear domain. Unfortunately, the lin2db block and dB2lin block appear to be CPU% hungry. Times six, in case there are six channels.

There exist various analog audio compressors-limiters, that are managing the gain (attenuation) in various unspecified domains defined by some vacuum tube in low V anode-cathode region, some JFET in low VDS region, some BJT in low VCE region, some vactrol (LED + LDR), etc. all recognized as working satisfactory. All providing transfer curves lying between "log(x)" and "sqrt(x)".

Speaking of digital, why not trying the sqrt(x) domain?

I am making such proposition, because the Flowstone Assembly Code component supports the x86 sqrtps xmm1,xmm0; instruction, much faster than a lin2db block. Consequently, the side-chain can manage the gain (attenuation) in sqrt(x) domain. At the beginning of the side chain, instead of placing a lin2db block, we place a sqrt(x) block, much faster than a lin2db block. At the end of the side chain, instead of placing a db2lin block, we place a x^2 block, much faster than a db2lin block.

I am attaching a .fsm, showing the validity and precision of the x86 sqrtps xmm1,xmm0; instruction.

sqrt(x) function for audio.fsm

(12.08 KiB) Downloaded 857 times

sqrt(x) function for audio (650 pix).jpg (100.12 KiB) Viewed 10398 times

Have a nice day