New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 3
Type: Task

Sign in to add a comment

Issue 853196: Feedback on using experimental native echo cancellation in Chrome

Reported by, Jun 15 2018 Project Member

Issue description

Starting in Chrome M68, we'll run an Origin Trial to evaluate the system-level echo cancellers in macOS and on Windows, as well as a new constraint to allow apps better control over which echo canceller is being used.

If you're signed up to that Origin Trial, please leave your feedback here.

Comment 1 by, Jul 11 2018


Comment 2 by, Jul 16 2018

Hi Oskar,

I'm trying to enable the feature locally by the following command:
open -n -a "Google Chrome" --args --enable-blink-features=ExperimentalHardwareEchoCancellation

But the output from navigator.mediaDevices.getSupportedConstraints() does not list echoCancellationType. Nor does audioTrack.getCapabilities() or audioTrack.getSettings().

Is there something I'm missing to enable the feature? I'm running 68.0.3440.59 (Official Build) beta (64-bit)

Comment 3 by, Jul 16 2018


getSupportedConstraints(), getCapabilities() and getSettings() now all return echoCancellationType but I can't seem to set it to 'system' to with this call:

  audio: true,
  echoCancellationType: 'system',
  video: true

getSettings() always returns 'browser'

Comment 4 by, Jul 18 2018

Ah, no, you need echoCancellationType as part of the audio constraints, i.e:
  audio: { echoCancellationType: 'system' }

Comment 5 by, Jul 18 2018

Thanks for the clarification but even with

  audio: { echoCancellationType: 'system' },
  video: true

I still see echoCancellationType: "browser" when I check with the following:

audioTrack = stream.getAudioTracks()[0];

This is on MacOS btw.

Comment 6 by, Jul 18 2018

Under chrome://flags, is "WebRTC Echo Canceller 3" the correct experiment?

Comment 7 by, Jul 24 2018

No, Echo Canceller 3 is a separate experiment. I'm unsure if it will interfere with this one, but would disable it if you've enabled it.

Comment 8 by, Sep 17

Hi, I'm experimenting it on Chrome M69 for a phone system and it works great (better than AEC3 for now). 
I had many issues with fade-in/fade-out that are fixed with the native echo cancellation (experimented on MacOs > 10.12 and under experimentation on Windows).

Is there any news about an "official" release?

Comment 9 by, Oct 3

Good to hear it's working out for you! We are still evaluating, so no set timeline for general release yet.

Comment 10 by, Nov 19

Hello again!I'm continuing to use the Native Echo canceller and it works great when the user is using the built-it microphone device but I don't know why the getUserMedia function take a lot of time when I use ({echoCancellationType: 'system'}) as constraint it take a lot of time (between 1 and 3 seconds) and memory usage.
Do you have any explication?

Comment 11 by, Nov 20

Setting up the native echo canceller is known to take a bit of time, though three seconds does seem high. There could be some reconfiguration involved, but that shouldn't be the case if you're just using built-in devices. Are you, or are you using an external playback device?

The memory thing is interesting. If you can provide numbers comparing with and without the 'system' echo canceller, that would be greatly appreciated!

Comment 12 by, Nov 20


Comment 13 by, Nov 21

Ok I figured out that the long getUserMedia issue is linked to MacOS Mojave if can help.
Anther weird behavior is that when I use the native echo canceller on MacOS and I'm using an USB headset can happen that the headset microphone is turned off and the system start to use the integrated (Built-in) microphone.
I've noticed that when this echo canceller type is activated in the chrome://webrtc-internals you can see sometimes that the echo canceller is setted to {ideal: [deviceId]} do you know why and if meaning that the echo canceller used is the one in the specific deviceId ?

Comment 14 by, Nov 23

More feedback after 2 days of hard testing:
A very weird issue: 
MacOS Mojave 10.14 and Chrome v70
1) Open a music player (tested with Spotify, iTunes and youtube opened on Safari)
1) In Chrome load a page that run `navigator.mediaDevices.getUserMedia({audio: {echoCancellerType: 'system'}})`
2) unplug and plug a jack headset
3) the laptop audio volume max is lowered more than 50% and no way to recover it without closing the page tab or restart the audio from terminal with `sudo launchctl stop && sudo launchctl start`

Comment 15 by, Nov 23

#14: that might be caused by apples very own "ducking" variant -- see ; i've heard similar things about Safari before.

Comment 16 by, Nov 26

Re #13:
Thanks for reporting this! Can you please give reproduction steps for the issue when the microphone is turned off?

deviceId sets the device to use and is not related to which echo canceller is used.

Re #14:
I can't reproduce this. I get an initial lowering of volume every time I plug in or out a 3.5 mm jack headset, but it recovers after a second or so. I'm using macOS 10.13.6 and Chrome 70. Maybe it's Mojave related.

Comment 17 by, Nov 26

Re #14: Can't repro with Mojave either.

Comment 18 Deleted

Comment 19 by, Nov 26

Re #14:
If I load the attached page on a MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports), Chrome v70, headset plugged on start: I have this issue each time that I unplug and plug my headset.
757 bytes View Download

Comment 20 by, Dec 14

After the last chrome update (v71) all ours calls on Windows use 'browser' or 'AEC' as echo canceller even if we request 'system'.
I read that you are A/B testing but it seems that 'system' is completely bypassed: am I right?

Comment 21 by, Dec 14

Hi. The Windows system echo canceller support has been removed due to insufficient quality.

Comment 22 by, Dec 14

thank you for the response!
It was the only echo canceller that worked well on the `fade in fade out` issue (echo canceller too aggressive that cut down the voice).
We tested AEC3 and the issue is always there: are you working on it?

Comment 23 by, Dec 14

That's interesting. How did you find its echo performance? In our testing, we found it to leak too much echo which is more-or-less the opposite of the ducking you're seeing, where an echo canceller instead suppresses the signal as a whole to reduce echo.

What version of Chrome did you try AEC3 on? M70, M71 or both?

Comment 24 Deleted

Comment 25 by, Dec 14

We tested on both we still have the issue.
We found it because our customers call to mobile devices that are often in a very noisy environment (street, people around, ..): in this particular scenario, the mobile receiver hears a very muffled voice and the `muffled effect` corresponds to the noise peaks.

Comment 26 by, Dec 14

To add some context to Alessandro's comment, we're also able to reproduce the issue (also in M71) as explained here:

We were using native AEC on windows until 71 and it worked great to solve this.

Comment 27 by, Dec 14

Regarding echo leaking: we're not really impacted by echo leaking so we can't really tell you if we are seeing improvements on that side; our issue has always been lack of transparency in a context of noisy environment.

Comment 28 by, Dec 19

Just to have an idea and deal with this issue: do you guys plan to re-introduce native AEC for Windows anytime soon? Or should we act as if it won't ever be possible again to use native AEC on Windows? It had a huge impact for us and our customers and now we are starting to see the issue re-appearing.


Comment 29 by, Dec 20

Hi guys,
just to know if we have to face this problem in the next Chrome release: do you plan to remove the native echo cancellation support for MacOS too in M72?

Comment 30 by, Dec 20


We're not planning on removing support for the MacOS echo canceller in M72, but have finished evaluating it. Our conclusion is that it will be removed at some point, but not right now.

We have no plans of reintroducing support for the Windows echo canceller.

Regarding the issues you're having with the WebRTC AEC, I'll follow up with some questions in . It's best to keep the information collected in that bug.

Sign in to add a comment