PSA: Changes to C++ webrtc::AudioProcessing interface for echo cancellation configuration

[Sam Zackrisson]

Hi all,

You can stop reading if your code doesn't configure AEC (acoustic echo cancellation) via the webrtc::AudioProcessing interface.

What’s changing?

On August 16:

• The flag webrtc::AudioProcessing::Config::EchoCanceller::enable will apply to all echo cancellation performed by the audio processing module, both injected and built-in AECs. (It's currently a no-op.)

• The flag webrtc::AudioProcessing::Config::EchoCanceller::mobile_mode will determine which built-in AEC is used, if no injected AEC is present.

On September 4:

• We remove the interfaces webrtc::EchoControlMobile and webrtc::EchoCancellation.

What do I need to do?

Before August 16, you need to set the fields of a webrtc::AudioProcessing::Config in tandem with your current AEC configuration, and call AudioProcessing::ApplyConfig with it.

After August 16 and before September 4, you will need to stop using the old AEC interfaces.

How?

Here's one example for using the config in tandem, below are more examples of config usage:

rtc::scoped_refptr<webrtc::AudioProcessing> audio_processing =  ... ; webrtc::AudioProcessing::Config config = audio_processing->GetConfig(); // Example: Enable AEC effect, and set builtin echo cancellation (if used) to AEC2. config.echo_canceller.enabled = true; config.echo_canceller.mobile_mode = false; // Example: Enable AEC effect, and set builtin echo cancellation (if used) to AECM. config.echo_canceller.enabled = true; config.echo_canceller.mobile_mode = true; // Example: Disable AEC effect. config.echo_canceller.enabled = false; // Customize the rest of config. ... // Apply all settings in config, including unchanged defaults. audio_processing->ApplyConfig(config);

The remaining settings in webrtc::EchoControlMobile will be non-configurable: We’ll cement the current defaults for routing mode (speakerphone) and comfort noise (disabled). Set/get echo path will be deprecated.

For webrtc::EchoCancellation, the suppression level will be the by far most used setting (high suppression), and drift compensation the current default (disabled). Metrics are still available via AudioProcessing::GetStatistics(). stream_has_echo() and aec_core() will be deprecated.

Why are you doing this?

These pointer-to-internal-component interfaces restrict our threading model and internal refactoring, and expose a lot of little-tested legacy code. If you have any questions, feel free to reach out.

[Sam Zackrisson]

Landed the first step now, for AEC2/AECM configuration. Injected configuration may need to wait, will work as before until then.

https://webrtc-review.googlesource.com/c/src/+/94771

[Vitaly Ivanov]

Hi Sam,

Thanks for the heads-up! Couple of questions regarding AEC if you don't mind:

1) What's the status of AEC3? I tried it about a year ago in an app I work on (uses some carefully extracted bits of WebRTC like audio_processing and desktop_capture), it did a great job of suppressing echo, but was too aggressive and distorted/ducked good voice signal way too often. I had to revert the change after a few days of testing.

Let me rephrase the question to be more specific: if I get the latest stable Chrome/Chromium right now, all default settings, and launch https://appr.tc, will it use AEC3 internally?

2) You mentioned built-in/injected AECs, did you mean native macOS AEC as an example? I wonder if https://developers.google.com/web/updates/2018/06/more-native-echo-cancellation is planned to be part of WebRTC any time soon?

Thank you!

[Sam Zackrisson]

The AEC2/AECM interfaces have been removed.
https://webrtc-review.googlesource.com/c/src/+/103444

Injected AECs (i.e. implementing webrtc::EchoControl) will keep overriding the config enabled flag, for now.