lin2db & db2lin (expanders, compressors, limiters)

[steph_tsf]

Martin Vicanek x86 SSE lin2db & db2lin components, precise to 1e-7 (perfect from -120 dBFS to 0 dBFS) reign in dynamic expanders, compressors and limiters. One is tempted to let them operate at Fs, for reaching a maximal, perfect smoothness. Unfortunately, they occupy the CPU, an order of magnitude more than one is accustomed with IIR Biquad filters.

What kind of penalty do we incur in case we let the (expander, compressor or limiter) side-chain operate in square root domain, instead of in decibel domain?

The goal is to rely on near-trivial x86 SSE lin2sqrt & sqrt2lin routines in the side-chain. The CPU occupation becomes minimal, quasi negligible.

Of course, variants of the of x86 SSE lin2db and dn2lin routines remain necessary for ensuring the calibration of the knobs graduations. They only need to get executed when a knob gets moved. Which means once every year, speaking of hearing aids.

[trogluddite]

That's a very interesting question - and I wonder even whether it has a definitive answer.

Where the decibel is used for technical measurements, there is no doubt that it is very effective. It's original purpose was the measurement of transmission losses along telephone cables, where it models losses vs. cable length very nicely indeed (and hence "Bel", from Alexander Graham Bell, first patentor of the telephone - though under somewhat controversial circumstances!).

But when decibels are used to measure loudness, we're implicitly assuming that human loudness perception consistently follows a power law. Experimental evidence seems to indicate that this is a reasonable approximation and sound-engineers seem to find it useful enough in practice; but it is doubted by some researchers, since auditory perception is affected by so many factors besides sound pressure (e.g. frequency and bandwidth; conflicting simultaneous sounds; cognitive attention; damping by the tensor tympani muscle, etc.). Experimental environments may be gross simplifications of real-world cirumstances, and perceptual studies are notorious for "1st-world college student" subject-selection bias! Even if it is a reasonable assumption for subjects with typical hearing, it may be unsuitable for those with hearing impairments, and may be dependent upon the type of impairment (my own experience of atypical perception due to Asperger's syndrome certainly suggest to me that it is not applicable in all cases).

So it's entirely possible that a decibel-scaled transfer function is not optimal for your application in any case, regardless of technical considerations (nor your suggested alternative, of course). The pragmatic answer is that you will have to try it and test empirically whether it suits your application - you may have stumbled upon a novel and extremely effective solution for your particular case (or not), regardless of what any numerical analysis might suggest (which I shall leave to those more capable of it than myself!)

My personal opinion is that you would do better to focus on the practical effectiveness of your solution, and to leave CPU load considerations and optimisations until you have this nailed down. Should your proposal for an open-source hearing aid be successful, the x86 architecture would not be a practical target platform in any case (besides some kind of "dumb" fitting interface via cable/wireless). There is certainly no harm in learning optimisations for the purpose of becoming a more resourceful programmer; but as reknowned computer scientist Donald Knuth once said; "premature optimisation is the root of all evil" (i.e. you may be squandering effort on code which you later discover is either no longer required or is not a significant performance bottleneck in practice).

[steph_tsf]

Thanks for warning me about the dangers of a premature optimization.

The "square root side-chain domain" idea came to me after realizing that ages ago, surely there were compressors and limiters said to work fine, in analog domain, embedding gross & inaccurate log & antilog approximations. It became obvious that there was a degree of freedom, one could exploit.

An encouraging fact is that the 32-bit FPU precision ensures a near-perfect [x^0.5 -> x^2.0] reconstruction over 140 dB. When the transfer function will say 3.456 "over", of course this is not anymore 3.456 decibels "over". Instead, this is now 3.456 zanzibar "over". I thus foresee that there will be no error committed in steady state. Speaking of a limiter (actually a compressor whose compression ratio is set to infinite), the specified "limit" now expressed in zanzibar instead of decibels, will be precisely obeyed. Right?

By extension, speaking of a compressor whose compression ratio is set between 1.0 and 5.0, I bet that the threshold level will be precisely obeyed. Right?

The only remaining doubt goes about the faithful observance of the compression ratio that's specified. Any idea ? No need to say, a gross static discrepancy would render the "square root side-chain domain" idea, worthless.

My intuition is that there won't be any static discrepancy.

My intuition is that there must be a dynamic discrepancy, letting think there is a parasitic variable Fc lowpass filter in the side-chain, featuring a Fc that's monotonic varying with the instantaneous (always positive) level. From a perceptual point of view, it may be beneficial, or detrimental. One may like. One may dislike. Surely it depends the audio material: speech, music, street noise, etc. I am curious to listen to that.

Anyway, adding a physical lowpass filter in the side chain, should tame any perceived difference. Unfortunately, such easy fix will increase the reaction time.

A last resort fix could consist in inserting a continuously variable Fc shelving filter acting as compensation. This way a constant, short reaction time could be maintained, whatever the instantaneous level. Cost is a Dynamic IIR filter doing fine when Fc is in the order of 5 to 50 Hz (such cost remains light), along with its Dynamic Controller (unfortunately, such cost appears to be heavy). For this to make sense, the total compensation cost must remain several times lighter than the ultraprecise Martin Vicanek lin2db & db2lin cost, we want to eject.

Any comment welcome

[trogluddite]

Thanks for warning me about the dangers of a premature optimization.

I have to warn myself on a regular basis - I'm very prone to getting stuck in the tar-pit of optimisation, only to find that I completely rewrite my code later when inspiration for a better algorithm strikes!

...surely there were compressors and limiters said to work fine, in analog domain, embedding gross & inaccurate log & antilog approximations. It became obvious that there was a degree of freedom, one could exploit.

That's certainly true. A good example might be the enduring popularity of optical compressors, where the gain control element is the combination of a light-source (brightness approximating audio power) and a photo-resistor. Besides non-linearities in the gain curve, this combination also results in attack/decay rates which vary widely in response to the signal content (in particular, faster gain recovery times for shorter time periods over the threshold). This was one of the very earliest implementations of compression, and is still so favoured by some sound-engineers that vintage units can fetch eye-wateringly high prices (the "desirable" photo-resistors having since been deprecated due to their highly toxic Cadmium content).

[steph_tsf]

Ah, the LED + LDR combination. Vactrol. Still popular on eBay. The LDR is shunting the audio signal to the ground. When mated to a 0 dBm 20 Kohm audio source resistance, it provides a easy to handle line-level 0 dB -> -30 dB attenuation. Without much distortion and noise. The Bang & Olufsen Beomaster 1900/2400 HiFi receivers rely on this as stereo volume control. More LED current is causing more attenuation. Speaking of compressors and limiters, the envelope detector can consist in a AC voltage doubler, rectifier, NPN Darlington as buffer, 22µF ... 220µF storage capacitor and NPN LED driver. All discrete. Will run on four NiMH AAA batteries in series. No power drain in the absence of audio signal. No on/off power switch required. No ground loop. The stereo PCB can be as small as the battery holder. Surprisingly rugged and effective in real life conditions. Been there, done this in the late seventies. Nice memories. Thanks. I never got the opportunity to check it on a dual-channel FFT analyzer and digital storage oscilloscope. I may build one again, for checking it. Nowadays, one can simulate and tailor the transfer law, attack time and release time using LTspice, as there is a LTspice "vactrol" model lying around.

[wlangfor@uoguelph.ca]

look around for the Sam Mungall lindb VCA (optimized by barak), you can use it to replace the entire control envelope assembly within a certain degree of exactitude. It's not finite but it is very efficient. I have in the past replaced the algorithm so that the db output was within four decimals of perfect, which is better tbut I was troubleshooting something and lost all My hard work due to a fork. Some time I'll re-do that work.

Actually, though this is a different topic; I've also come up with an algorithm which removes and volume addition and subtraction from the use of stereo width. I was surprised however that there's a slight deviance in the phase which seems in-avoidable. It also seems to fluctuate based on the width, to a grade that is not a linear scale :/.

I've been able to take limiters and compressors using 2% or 3% to only use 0.09 - 0.5% using the DB linear Sam Mungall VCA asm code optimized by Barak however.

It's always imperfect codes that save the most mem.
GL