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.
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.
Please, file bug reports for any issues you find with AEC3. This is how to do it:
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.
Open chrome://webrtc-internals in a new tab.
Expand “Create Dump”.
Check “Enable diagnostic audio recordings”. A file dialog will show. Select a folder and base filename (the default suggestion is fine).
Make sure that you experience the problem while the recording is running.
Uncheck “Enable diagnostic audio recordings” to stop the recording.
You should now have a number of files beginning with your base filename.
Copy all the information from chrome://version.
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!
/Henrik – on behalf of the WebRTC developers
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiK225645%3DxxLLfRDLF8uMyGz%3D-V1u7eLgy1zg%2BpfO49bg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/791d509a-e931-4ee1-ba33-25864cdabfe6%40googlegroups.com.