How to avoid loudness reduction for sustained tones?

[David P]

We've noticed in recent versions of Chrome on Win10 and Mac that when a person sings a sustained note for ~7 seconds, the loudness reduces for others on the call in a steady decline for several more seconds. We don't use any of the "goog" legacy webrtc settings for gain, nor do we adjust gain in our SFU.

Is this part of a recent change in Chrome echo cancellation, and can it be disabled via call config?

[stron...@gmail.com]

This can be caused by the noise suppression module, since sustained note is stationary thus easily classified as background noise in noise estimation.

[David P]

Can it be disabled via js?

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/PDZYMzAI-_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ddebff7e-a6c6-4c72-bebe-f92ea428b971n%40googlegroups.com.

[The V]

My guess would be it's AGC, not NS. WebRTC uses VAD (voice activity detection) part of JM Valin's RNN denoiser for AGC, and constant tone probably gets a very low VAD score which leads to gain decrease. Do you use something like `googAutoGainControl: false` to make sure all sorts of gain control are off?

You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAE23trvqDQ%2BP86zMDoGmVTgHkfCaafdtzsO99ns0KK-q3OYo9w%40mail.gmail.com.

[davidsw...@gmail.com]

I want to revisit this thread I started three years ago because it's still a problem in Chrome as recent as 119. It is interfering with telehealth sessions in which the patient needs to hold a vowel sound like 'ewww' for about 20 seconds: After about 3 seconds, the patient's audio becomes too quiet to hear by the remote clinician. This occurs on Chrome, Firefox, and Safari on Windows10, macOS, iOS, and Android.

It is most pronounced on Samsung A7 tablets with Chrome 119. (And much less on Pixel 7/Android14 phones with Chrome 119.)

We have tried setting both noiseSuppression: false and autoGainControl:false but that makes no discernable difference on any browser/device combination we've tried.

[Khun V]

Could this be caused by AEC? You only mentioned NS and AGC in your email

On Fri, May 3, 2024 at 12:39 PM David Röttger <da...@sirius.video> wrote:

I'm also racking my brain and can't explain how it occurs on some devices and not on others. Our users also report tones dropping out even though the noise suppression filter on the other end is off.
Again, does anyone here have any idea what might be causing this?

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/95cff550-8329-4398-b5a7-aab03a057bc0n%40googlegroups.com.

[David P]

It's funny you should ask this week. I'm the original poster, and I found a technique just days ago that works for us.

When the WebRTC bugtracker was migrated to a new platform last week, the search function became more usable. I found this 2018 nugget:

 https://issues.webrtc.org/issues/42233375#comment13

Setting echoCancellation: {exact: false} worked on all non-Safari browsers I tested on:

+ Win10 (Chrome and Firefox)

+ macOS (Chrome and Firefox)

+ Android 13 Samsung tablet (Chrome)

+ Android 14 Pixel 7 phone (Chrome)

And although it doesn't work on Safari (and all browsers on iOS are just skins of Safari), the following similar technique does work:

noiseSuppression: {exact: false}

There will be an echo (if a mic picks up speaker output from any audio from other attendees), but you might be able to mitigate this if you can mute all but the current active participant.

What's the best way to detect which technique to use? Relying on user-agent parsing is not a good way. One should be able to rely on getCapabilities of the audio input track, but Safari does not include noiseSuppression among its capabilities (although it does work). And getCapabilities is not reliable for 'exact' constraints.

Safari throws an OverconstrainedError if you request echoCancellation:{exact:false}

at least it does for me when also constraining deviceId. But I suspect that wrapping with a try...catch, and constraining noiseSuppression in the catch, will probably work. (To be tested next week.)

Tell us if this works for you.

On Fri, May 3, 2024, 8:39 AM David Röttger <da...@sirius.video> wrote:

I'm also racking my brain and can't explain how it occurs on some devices and not on others. Our users also report tones dropping out even though the noise suppression filter on the other end is off.
Again, does anyone here have any idea what might be causing this?

On Tuesday, December 12, 2023 at 1:43:34 PM UTC+1 davidsw...@gmail.com wrote:

--

This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/PDZYMzAI-_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/95cff550-8329-4398-b5a7-aab03a057bc0n%40googlegroups.com.

[davidsw...@gmail.com]

Although using applyConstraints with echoCancellation: {exact: false} was working on Chrome 124 for Android 14 on a Pixel 7, using the same device with Chrome 126.0.6478.122 now produces OverconstrainedError. The Android version is the same but a security update was applied June 5, after my success above.

libwebrtc team, is this a new working-as-desired behavior? It interferes with a procedure common in telemedicine, which is to say "aaaaah" for as long as one can...because it attenuates the audio too much.