Noisegate level and 'slope' value settings (in context of gain_camfit_compr)

Post Reply
sgraetz
Posts: 3
Joined: Mon Apr 20, 2020 3:35 pm

Noisegate level and 'slope' value settings (in context of gain_camfit_compr)

Post by sgraetz » Fri Oct 30, 2020 9:36 am

Dear OpenMHA developers,

I am wondering whether you could please advise us about the noisegate “slope” settings as defined in the Camfit compressive function. Why is the noisegate “slope” value set to 1 in all bands? Is it defined on the basis of the noise floor in OpenMHA hardware or does this come from an interpretation of the Camfit compressive prescription, or is there some other basis? We are using dc as our compression plugin.

As an aside, I note that the default noisegate level setting in this prescription is 45 dB in all frequency bands, but we have changed this to levels in each band that correspond to the levels of a speech-shaped noise signal with an overall level of 45 dB SPL, in accordance with our interpretation of the Moore et al. (1999) paper.

Many thanks
Last edited by sgraetz on Fri Nov 13, 2020 2:35 pm, edited 1 time in total.

tobiasherzke
Posts: 109
Joined: Mon Jun 24, 2019 12:51 pm

Re: Noisegate level and 'slope' value settings (in context of gain_camfit_compr)

Post by tobiasherzke » Fri Oct 30, 2020 12:46 pm

One function of the noise gate is to protect the wearer from perceiving soft "sounds that the person may rather not hear", as Dillon puts it [1]. Another function is a decreased likelihood of feedback for low input levels. Of course it also prevents audibility of the microphone noise.

With Moore 1999 I think you are referring to [2], and the camfit_compression method implemented for openMHA after this paper. This paper defines a fitting rule and does not propose any specific noise gate settings as far as I can see. With a default noise gate of 45dB SPL in each band, we are providing lower gains than defined by the paper at low levels.

Please feel free to adapt the onset and slope settings to what works for you. Distributing the 45dB across the frequency bands according to a speech-shaped spectrum is a reasonable approach, also suggested in [1]. But even then you would still provide lower gains at low levels than defined in [2]. To ensure that you apply all the gains defined in [2], you would have to set the noise gate threshold to 27dB LTASS-equivalent band level (45-18), which for real devices is most likely below the microphone noise, and therefore too low for practical noise-gate purposes.

Therefore, some compromise between fitting-rule prescribed gains and real-world noise-gate requirements has to be made. Please view the default settings as only a suggestion and feel free to modify them.

[1] Dillon, Hearing Aids [book], 2001, p.309 (do not have the 2nd ed. at hand at the moment)
[2] Moore, B. C. J., Alcantara, J. I., Stone, M. A., & Glasberg, B. R. (1999). Use of a loudness model for hearing aid fitting: II. Hearing aids with multi-channel compression. British Journal of Audiology, 33(3), pp157–170.

sgraetz
Posts: 3
Joined: Mon Apr 20, 2020 3:35 pm

Re: Noisegate level and 'slope' value settings (in context of gain_camfit_compr)

Post by sgraetz » Fri Nov 13, 2020 1:55 pm

Thanks for the clarification, Tobias. It's good to hear that you think our 'noisegate threshold' settings are reasonable. In our case, there is no physical hearing aid and all of the processing is done offline.

I've set the 'noisegate slope' to 0 in gainrule_camfit_compr and gainrule_camfit_linear to obtain a slope of 1 below the compression threshold.

We are still concerned that the compression ratios are usually "maxing out". Are there any known issues with the gainrule_camfit_compr code? Is it consistent with the Moore et al. 1999 paper?

tobiasherzke
Posts: 109
Joined: Mon Jun 24, 2019 12:51 pm

Re: Noisegate level and 'slope' value settings (in context of gain_camfit_compr)

Post by tobiasherzke » Sun Nov 15, 2020 6:51 pm

As you have seen, our implementation differs from the publication with respect to the noisegate.

Another difference that I am aware of is that our implementation does not apply negative gains. If I remember correctly, the method from the publication can prescribe negative gains, e.g. for an audiogram of 0dB HL at all frequencies.

You are concerned about the compression rate limit, and that you run into the limit often. It is good that you are concerned. Since the published method is quite simple to compute, I invite you to check if our implementation computes the same gains as you would do by applying the published method manually from the papers. You could perform this check by reviewing our code or by comparing outcomes. Either way, please report your findings here!

sgraetz
Posts: 3
Joined: Mon Apr 20, 2020 3:35 pm

Re: Noisegate level and 'slope' value settings (in context of gain_camfit_compr)

Post by sgraetz » Mon Nov 16, 2020 12:15 pm

Thanks Tobias.

Is it the case that the following code for computing the compression ratios in gainrule_camfit_compr is causing the mismatch, specifically, the index 'end'?

max(Lmid+Gmid.(side)(end,:)

Perhaps the index could be changed to whichever level corresponds to 65 dB or the level of interest?

tobiasherzke
Posts: 109
Joined: Mon Jun 24, 2019 12:51 pm

Re: Noisegate level and 'slope' value settings (in context of gain_camfit_compr)

Post by tobiasherzke » Mon Nov 16, 2020 4:55 pm

Thank you! You have found an error in our implementation.

I think index "end" is used there because Gmid is computed from camfit_linear, and as a linear fitting rule, it supposedly assigns the same gain to all input levels.

However, in commit https://github.com/HoerTech-gGmbH/openM ... 3134856bc2 I have introduced a default MPO into camfit_linear without being aware of the implications on camfit_compr with the end index.

As a workaround, I suggest changing \(\texttt{Gmid.(side)(end,:)}\) in that line to \(\texttt{max(Gmid.(side))}\).

We will release a proper fix ASAP. Thank you again! If you find any more issues, please report them here or in our github repository.

tobiasherzke
Posts: 109
Joined: Mon Jun 24, 2019 12:51 pm

Re: Noisegate level and 'slope' value settings (in context of gain_camfit_compr)

Post by tobiasherzke » Fri Nov 27, 2020 10:51 pm

We will release a proper fix ASAP.
A fix for the error that you found was released today in openMHA version 4.13.0.

Post Reply