Audio Compression & Limiting - low CPU%

[steph_tsf]

What building blocks would you recommend for keeping the CPU% under 24% while executing 24 Audio Compressors-Limiters, processing 16-bit audio streams?

peak envelope follower (attack time, release time)
RMS envelope follower (attack time, release time, rms time)
lin2db translator
db2lin translator
compressor law (T1 threshold, C1 compression ratio)
compressor & limiter law (T1 comp threshold, C1 comp ratio, T2 limit threshold, C2 limit comp ratio)

This is for emulating a 6-band stereo hearing aid (see the attached .fsm). Barebone. Not yet reliable, due to some initialization malfunction. Please let me explain. After loading (it fails loaging randomly), for the various modules to take effect, one is obliged to wake-up the bypass switches, some pots and some selectors. How to solve this? Any sort of guidance will be highly appreciated.

Multichannel Hearing Aid Emulator (audio off).fsm

(425.08 KiB) Downloaded 1077 times

Multichannel Hearing Aid Emulator (audio on).fsm

(425.13 KiB) Downloaded 1112 times

The bandwidth limiting IIR filters at the input (a highpass followed by a lowpass) can be Butterworth or Bessel, of any order (slope) between 1 and 8.

The band-splitter is a IIR Linkwitz-Riley array equipped with all required phase followers. I had great fun designing this. Albeit looking funky, and possibly naive, It guarantees a perfect bands recombination. Unfortunately, not phase-linear. I mean, the global phase. One can change the band-splitting filters order (slope). Please note, upon specifying F1 (lowest crossover frequency pot) and F2 (highest crossover frequency pot), all crossover frequencies get automatically calculated in logarithmic progression.

In case you know more efficient band-splitters that are guaranteeing a perfect bands recombination, please let me me know.

- I am considering a IIR bidirectional filter array as alternative (phase linear thus), because then, a simple delay per channel suffices as phase (delay thus) equalizer. Hope the latency won't cause an issue in case 100 Hz is the lowest frequency to be reproduced.

- I guess there may be other possibilities, like warped-IIRs or warped-FIRs. Right?

The RMS envelope follower, lin2db translator, db2lin translator, compressor law are not my conception. In case you recognize one or another as yours, please tell and I'll be glad to add credits inside the corresponding module.

Your comments and suggestions are always welcome.

[MichaelBenjamin]

.

[steph_tsf]

You are right. The whole compressor is already in mono4. I've chosen 6 channels, because 6 channels * mono4 = 24 channels. There in no need for a 24 channels audio DAC. In case you open the schematic, you will realize that the 24 bands get recombined inside the schematic. The physical output is only 2 channels. One channel per ear. What's worrying me, is that in case one cannot merge the compressor with the limiter, the CPU load will increase two folds. Which means I will reach a 50% CPU use. Please tell me, is it conceptually wrong to merge the gain, the compressor and the limiter, now that we are 32-bit floating point?

[martinvicanek]

What a great project! Thanks for sharing! I had no idea how hearing aids work. From your post I learn that you split the audio into bands and compress and level-adjust each band individually. Makes sense!

I did some profiling of your schematic and the most CPU load is generated from the band splitter. So if you want to harvest these low hanging fruits, you could try the attached band splitter. It is not optimized to the max, however I think it is lighter than yours.

6bandsplitter2.fsm

(150.08 KiB) Downloaded 1074 times

Edit: a bit more optimized version:

6bandsplitter3.fsm

(181.92 KiB) Downloaded 1096 times

I was wondering if L and R should not be adjustable individually?

[steph_tsf]

Hi Martin, I like the hierarchical tree decomposition. Consequently, let's concentrate on 8-band spliters. This way there is no need to waste CPU% in doing the two parasitic merges. The global optimization that you provided, allows to cope with 8 compressors-limiters, instead of 6.

Have you measured your "fast pack" and "fast unpack" modules performance, against the standard ones?

Conceptually, speaking of a "exact" band splitter, I can't fully approve the way you organized the phase followers. Practically, I am forced to approve your choice, upon looking at the spectacular CPU% decrease you have provided.

A more elaborate tradeoff regarding the phase equalization branches, deserves to be applied. I am thinking this way, because currently, the odd orders provide a better selectivity than the even orders. This could be a malfunction indication. There may be a better tradeoff, consisting in only following the phases of the adjacent filters, and approximating the farther filters as pure delays. The difficulty consists in automating the calculation of the required delays, in the context of a configurable splitter whose Fmin split and Fmax split can be varied by the user.

See the attached .fsm

proposed 8-bandsplitters (block diagrams).fsm

(2.34 KiB) Downloaded 1092 times

By the way, I thank you for allowing me to "Close Encounters of the Third Kind" with the "alien" DSP you are basing on. I mean, the "ZD" Biquad filters you are basing on. The usual trigonometric calculations that are determining the IIR coeffcients in function of F and Q, are missing. You appear to base on a standardized "Padé IIR Biquad" that the x86 SSE DSP routine is editing using a few SSE instructions costing almost 0% CPU use, allowing true modulatability at almost 0% CPU cost. Is there literature about this?

Obviously, the filtering scheme is not emanating from Linkwitz-Riley. When you report a "7 poles" filtering, this is a single 7th-order IIR filter instead of two 3.5 order Butterworth filters hooked in series. I know a 3.5 order is unfeasible. Meanwhile, this is working very well. And, in your implementation, the various "ZD Biquad filters" all cut at the same "F" parameter (wireless) and all rely on a local, manually tuned "Q" parameter. The fact that all "ZD Biquad filters" are cutting at the same "F" parameter (wireless), prevents the implementation of Butterworth filters. This is not criticism. This is astonishment. I am truly, positively impressed by such "alien" DSP. How come, albeit being not Linkwitz-Riley filters, the LP and HP filters appear to be complementary?

By the way, the 1st order x86 SSE DSP routine you are relying on for implementing the odd orders, still requires trigonometric instructions for calculating the coefficients. Is it feasible to design a "Padé IIR 1st-order" filter, dispensing from a trigonometric calculation?

Regarding the compressor + limiter, I am envisioning a GTCL unit needing as input parameters :

G : the gain in dB
T : the compressor intervention threshold (referred to the input level, before applying gain) in dB
C : the compression ratio (between 1.0 and 4.9)
L : the limiter intervention threshold (referred to the output level, after gain and compression) in dB

I am in search of a limiter that's reading the input envelope follower, that's trusting the compressor, which means it suffices to read the input envelope follower and the "G, T and C" parameters, for determining the theoretical output level. This way the limiter doesn't require a output envelope follower. Quite a CPU% saving. Thus, basing on the theoretical output level, one can implement a compressor following the first one. The second one needs to be nested into the RubyEdit module that's determining the transfer law. There need to be a few more Ruby code lines over there, exploiting the "L" parameter in dB, along with a fixed "Z" compression ratio set to 10 that the user can't change. The whole structure remains thus feedforward, basing on a single envelope follower, and basing on a single RubyEdit module that's determining the transfer law. Consequently, the CPU% is only marginally heavier than the sole compressor. Does it make sense?

According to me, the L and R should not be adjustable individually. Quite unwanted are frequency responses that are varying a different way, from L to R. This is perceived as a disturbance. The user won't trust a hearing device combination whose left-right balance is randomly changing.

Your comments, always welcome.

[martinvicanek]

Wow, you have raised many points in your response! I'll need some time to fully comment. For now I'll say: no, no alien DSP inside, if you take a look at my tutorial it may become clearer. And yes, the filters are all Butterworth, hence the common frequency. Even orders are Linkwitz Riley where adjacent bands are in phase, odd orders have a 90 degree phase relation.

I'll respond to your other points later, especially regarding compressor design.

[k brown]

To maintain stereo imaging integrity, you do NOT want to compress L/R individually.

[martinvicanek]

To maintain stereo imaging integrity, you do NOT want to compress L/R individually.

I see your point and for a healthy person I fully agree. But what if a person's hearing capability is different for L/R (mine is)?

[martinvicanek]

Hi Martin, I like the hierarchical tree decomposition. Consequently, let's concentrate on 8-band spliters. This way there is no need to waste CPU% in doing the two parasitic merges. The global optimization that you provided, allows to cope with 8 compressors-limiters, instead of 6.

No problem.

Have you measured your "fast pack" and "fast unpack" modules performance, against the standard ones?

Yes, they are a bit faster, hence the labeling.

Conceptually, speaking of a "exact" band splitter, I can't fully approve the way you organized the phase followers. Practically, I am forced to approve your choice, upon looking at the spectacular CPU% decrease you have provided.

It may look a bit unusual, but it is "exact" within the limits of floating point accuracy. The trick lies in the ordering of allpasses and splitters. Refer to http://www.iwaenc.org/proceedings/2010/ ... ds/975.pdf.

A more elaborate tradeoff regarding the phase equalization branches, deserves to be applied. I am thinking this way, because currently, the odd orders provide a better selectivity than the even orders. This could be a malfunction indication. There may be a better tradeoff, consisting in only following the phases of the adjacent filters, and approximating the farther filters as pure delays. The difficulty consists in automating the calculation of the required delays, in the context of a configurable splitter whose Fmin split and Fmax split can be varied by the user.

See the attached .fsm

proposed 8-bandsplitters (block diagrams).fsm

Correct, there is a difference between odd and even order. It is not an error, rather a peculiarity that even orders are amplitude complementary while odd orders are power complementary.

By the way, I thank you for allowing me to "Close Encounters of the Third Kind" with the "alien" DSP you are basing on. I mean, the "ZD" Biquad filters you are basing on. The usual trigonometric calculations that are determining the IIR coeffcients in function of F and Q, are missing. You appear to base on a standardized "Padé IIR Biquad" that the x86 SSE DSP routine is editing using a few SSE instructions costing almost 0% CPU use, allowing true modulatability at almost 0% CPU cost. Is there literature about this?

Well, not exactly Padé but very similar: it is a rational function approximation to tan(f/2). Actually I might have chosen a better approximation with more terms since the coefficients are rarely ever updated (in this application) so CPU is not a concern.

Obviously, the filtering scheme is not emanating from Linkwitz-Riley. When you report a "7 poles" filtering, this is a single 7th-order IIR filter instead of two 3.5 order Butterworth filters hooked in series. I know a 3.5 order is unfeasible. Meanwhile, this is working very well. And, in your implementation, the various "ZD Biquad filters" all cut at the same "F" parameter (wireless) and all rely on a local, manually tuned "Q" parameter. The fact that all "ZD Biquad filters" are cutting at the same "F" parameter (wireless), prevents the implementation of Butterworth filters. This is not criticism. This is astonishment. I am truly, positively impressed by such "alien" DSP. How come, albeit being not Linkwitz-Riley filters, the LP and HP filters appear to be complementary?

For even orders they are Linkwitz-Riley. For odd orders they are simple Butterworth. I took the Q values from an old textbook.

By the way, the 1st order x86 SSE DSP routine you are relying on for implementing the odd orders, still requires trigonometric instructions for calculating the coefficients. Is it feasible to design a "Padé IIR 1st-order" filter, dispensing from a trigonometric calculation?

Sure, you can use efficient approximations for the 1st order filter coefficients, too. I didn't bother because we are really only calculating those every 4096 samples.

Regarding the compressor + limiter, I am envisioning a GTCL unit needing as input parameters :

G : the gain in dB
T : the compressor intervention threshold (referred to the input level, before applying gain) in dB
C : the compression ratio (between 1.0 and 4.9)
L : the limiter intervention threshold (referred to the output level, after gain and compression) in dB

I am in search of a limiter that's reading the input envelope follower, that's trusting the compressor, which means it suffices to read the input envelope follower and the "G, T and C" parameters, for determining the theoretical output level. This way the limiter doesn't require a output envelope follower. Quite a CPU% saving. Thus, basing on the theoretical output level, one can implement a compressor following the first one. The second one needs to be nested into the RubyEdit module that's determining the transfer law. There need to be a few more Ruby code lines over there, exploiting the "L" parameter in dB, along with a fixed "Z" compression ratio set to 10 that the user can't change. The whole structure remains thus feedforward, basing on a single envelope follower, and basing on a single RubyEdit module that's determining the transfer law. Consequently, the CPU% is only marginally heavier than the sole compressor. Does it make sense?

I didn't quite understand why you are using two envelope followers? I thought one would suffice. And I would suggest using a steeper than 1st order lowpass filter to reduce distortion. Here is what I mean: viewtopic.php?f=3&t=6274&hilit=compressor&start=10#p29575
My choice would be an iterated moving average or a Bessel filter with a look-ahead feature adjusted to the filter's group delay.
I am not sure about using Ruby for the transfer law (high CPU and hard to sync).

[steph_tsf]

Martin, you are right. I forgot that the IIR filter blocks that are forming a high-order Butterworth filter, all need to cut at the same frequency. I am ashamed. Meanwhile, the fact that the odd orders (that you organized as simple Butterworth) perform better than the even orders (that you organized as Linkwitz-Riley aka double Butterworth), is kind of pathology indication. IMO, you worked on the "clever" optimization & simplification of the phase following department, only for the odd orders, actually ruining the Linkwitz-Riley (even orders) performance. No offense. Just trying to explain what we see. Any better idea? By the way, a super-selective performance is not required, for avoiding the global frequency response to look like a staircase when the various gains are very differing. Your "odd order clever phase following optimization" remains thus top of the list, in the context of a 5th-order filtering, despite the small total reconstruction hiccup that one can observe. I am interested in comparing such scheme, that I consider as best compromise for the intended application, with a hybrid-compensated (only proximity phase followers, plus delays for farther stuff) Linkwitz-Riley bandsplitter, 6th-order (two 3rd-order Butterworth in series). This is for accompanying the 6 to 8 channels evolution.