1849079 - getUserMedia echoCancellation constraint stopped working on some videoconferencing sites

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P3)

Description

[[e-mail]]

Attachment: ff116 echo.mp4

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

I (and teammates) can reproduce consistently on gather.town using Firefox 116 (not 115). Use gather.town on Firefox 116 with speakers as the audio output device, with another participant. Have the other participant talk. They can hear themselves clearly, same as if echoCancellation is disabled.

Here's a Gather space to repro with if anyone is willing: https://app.gather.town/app/JmoHFjBuphRK73KT/firefox-echo-example

Actual results:

Other users hear a full-volume echo.

Expected results:

Other users should not hear an echo.

We call getUserMedia with echoCancellation: true and I verified that 'echoCancellation: true' appeared in the track.getSettings() on the microphone MediaStreamTrack when I reproduced this on my end. (In the attached video, I'm recording and my teammate is running FF116) Nothing has changed on our side in how we call getUserMedia, and this does not repro on Firefox 115.

I saw that FF116 introduced audio output device selection (which is awesome btw, very happy about that). Is it possible that echo cancellation depends on the selected output device or doesn't cancel out audio where the output device was explicitly set?

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Audio/Video' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Andreas Pehrson [:pehrsons]]

Thanks for filing! You are absolutely right in that the echo canceller will only be fed the output data of the default device. I filed bug 1849108 to get this tracked.

Comment 3

[[e-mail]]

Thanks Andreas! I'm seeing this echo even when I only have one audio output device. I think that means that if you explicitly call setSinkId with a specific device ID, even if it's the default device, the audio isn't part of the default MediaTrackGraph and thus isn't accounted for by the echo canceller. Is that right?

David

Comment 4

[Andreas Pehrson [:pehrsons]]

I think that is accurate, because when using the default output device we'll automatically switch when the user changes output device in system settings. With an explicitly opened one through setSinkId, we won't.

You should be able to verify this by looking at the number of audio output streams we have opened through platform APIs. If you have a live audio MediaStreamTrack there will always be an output stream open to the default device. You probably have two.

Comment 5

[[e-mail]]

Got it, that makes sense. Thanks again Andreas!

David