Help us test our new echo canceller

[Henrik Lundin]

Dear developers,

The new acoustic echo canceller (AEC) in WebRTC, called AEC3 will soon be fully launched. You are encouraged to try it in your WebRTC-based web applications today.

How to control the AEC

An Origin Trial controls the AEC type used in a call. This Origin Trial was announced in a blog post in September. The trial introduces an experimental MediaStreamTrack constraint, called echoCancellationType, to control which echo canceller to use. While the blog post details how to use this for activating the native AEC on macOS, it can also be used to switch between the legacy AEC2 and the new AEC3. Setting the type to ‘browser’ will force the old AEC2 to be used, while the value ‘aec3’ will select the new AEC. Selecting nothing will result in either AEC2 or AEC3 being randomly picked. See the blog post for details on how to sign up your site to the Origin Trial. (Read more about the concept of Origin Trials here.)

AEC performance is highly dependent on the audio hardware (computer and audio peripherals) and the acoustic environment. We recommend service developers to try out AEC3 on Chrome Beta M71 with hardware use-cases that are important to their product.

Expectations

In general, the performance of an AEC is perceived by the other end of a call, not by the side running the AEC. That is, any problem with the AEC on side A, such as failing to remove echo, will be heard on side B, not on side A.

AEC3 is expected to leak much less echoes than AEC2. Meanwhile, it is expected to provide the same level of transparency as AEC2. (Lack of transparency is perceived as “choppy audio” or half-duplex behavior, again heard on the other side.) But we need help finding the cases where we have to improve.

Reporting issues

Please, file bug reports for any issues you find with AEC3. This is how to do it:

1. Create a “diagnostic audio recording” from the endpoint causing the problem (remember, if you can hear the problem, the fault is on the other side). It is preferable if the recording is started before the call is set up, but starting mid-call works too.

1. Open chrome://webrtc-internals in a new tab.

2. Expand “Create Dump”.

3. Check “Enable diagnostic audio recordings”. A file dialog will show. Select a folder and base filename (the default suggestion is fine).

4. Make sure that you experience the problem while the recording is running.

5. Uncheck “Enable diagnostic audio recordings” to stop the recording.

6. You should now have a number of files beginning with your base filename.

2. Copy all the information from chrome://version.

3. Open a new WebRTC bug. Describe the problem and how to reproduce it. Carefully describe computer type and any audio peripherals used. Attach the audio recordings, and paste the version information.

Your help is much appreciated!

Thank you.

/Henrik – on behalf of the WebRTC developers

[Philipp Hancke]

asssuming you had the stats from chrome://webrtc-internals... is there something in there that seems to correlate strongly?

Like... mean value of googJitterBufferMs > 200 and a fairly large standard deviation?

--

---
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/CAOhzyfnJsrCJm%3DbAeqeKgwrb0mLzA%3DZT1sZenrFLQ9Zw27fhAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Henrik Lundin]

Long jitter buffer delays (even with large standard deviation) is not an indicator of AEC problems, per se.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiK225645%3DxxLLfRDLF8uMyGz%3D-V1u7eLgy1zg%2BpfO49bg%40mail.gmail.com.

[gab...@aircall.io]

Hi, thanks for the huge work on the AEC!

We'll try to test it intensively as we have a usecase where lack a transparency is a common issue. Out of curiosity, what is an indicator of AEC problems per se? E.g, can you track lack of transparency of AEC by analyzing webrtc-internals stats? 

Thanks,

Gabriel 

[Henrik Lundin]

Hi Gabriel,

We unfortunately do not have a live metric for transparency. It is hard to analyze the signal before and after the AEC and try to estimate how much of the removed audio was actually near-end speech that should have been left untouched.

Thanks for helping us try it!

/Henrik

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/791d509a-e931-4ee1-ba33-25864cdabfe6%40googlegroups.com.

[gab...@aircall.io]

Hi Henrik, 

We were also heavily using the native echo cancellation parameter (system) but it seems that since M71 this parameter is not taken into account anymore on Windows — it takes either AEC3 or AEC2, just like if we asked for 'browser'. Is the native echo cancellation experiment discontinued on Windows? 

Thanks a bunch,

Gabriel

[HostBBB.com]

Hi Henrick,  we are trying to get channelCount=2 (stereo mic) to work through the chrome AEC.   opus is in stereo, and we get the L/R speaker output fine from sender.,   but it appears the input left channel is just mixed to both L/R when we enable the echoCancellation.

Can AEC handle stereo input?

Firefox appears to handle it.

thanks

Stephen

[pe...@webrtc.org]

The issue with stereo AEC support is known and the current behavior in AEC3, where the stereo microphone input is mixed into a mono signal, was deliberately chosen to ensure a good quality until the full stereo functionality is implemented.

[Hauke Krüger]

Hi, is that Stereo plus AEC limitation still present? I can not get that setup running even in the latest Chrome release from sources ( Version 104.0.5103.0 ). Or is there a trick to work around?

Thank you

Hauke