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)

Update:

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

navigator.mediaDevices.getUserMedia({
  audio: true,
  echoCancellationType: 'system',
  video: true
})

getSettings() always returns 'browser'

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

Thanks for the clarification but even with

navigator.mediaDevices.getUserMedia({
  audio: { echoCancellationType: 'system' },
  video: true
})

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

audioTrack = stream.getAudioTracks()[0];
audioTrack.getSettings()

This is on MacOS btw.

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

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.

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?

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

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?

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!

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 ?

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 com.apple.audio.coreaudiod && sudo launchctl start com.apple.audio.coreaudiod`

#14: that might be caused by apples very own "ducking" variant -- see https://forums.developer.apple.com/thread/93995 ; i've heard similar things about Safari before.

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.

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

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.

Deleted: test.html 757 bytes

test.html 757 bytes View Download

Hello! 
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?

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

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?

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?

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.

To add some context to Alessandro's comment, we're also able to reproduce the issue (also in M71) as explained here: https://bugs.chromium.org/p/webrtc/issues/detail?id=8434

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

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.

Hello! 
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.

Thanks!
Gabriel

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?

Hi.

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 https://bugs.chromium.org/p/webrtc/issues/detail?id=8434 . It's best to keep the information collected in that bug.