My end is a Firefox Nightly on a Windows 10 machine (Lenovo Thinkpad W541), the other end is a Firefox Beta on a less powerful Windows 10 machine. I've managed to reproduce the echo issue with https://janus.conf.meetecho.com/echotest.html, so I have been able to run mozregression, which pointed me to https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=5bbdb7d36ee3c136a0ed03be9d5b012d05dfd08e&full=1. I'm not 100% sure here, as the issue could be intermittent, but I see something that might be related in that push (bug 1341285).

Here are the AEC logs for a real live call.

On Linux I can hear the same "ringing" echo from time to time, but it is not nearly as bas as on Windows.

There was no causality break in those logs. Marco's partner is generating a crazy amount of echo/feedback - louder than what marco sent out, and it's distorted/static-ey. It's almost as if the far-end has driven their speakers into clipping or a speaker is loose/rattling (which generates non-linear echo, which AECs do very poorly at cancelling since there's no good "math" way to calculate what the echo "should" be). Also, in that clip she never talked; the only audio from her side was echo/feedback. That makes it very hard for marco's canceller to train -- when both sides are feedinb back at each other, neither can train. To train, your AEC has to see a far-end signal and no local talking (no double-talk) - i.e. it has to see just an echo arriving at the mic (more or less). This is why AECs do poorly in noisy hotel lobbies. I'd love logs of both ends from a call with padenot (or anyone else), with the other using a headset. And a call with someone other than marco's normal partner, with the other person in speakerphone mode (logs at both ends). Padenot, can you do this?

marco, you're in London and I'm in Paris, it should be easy to make a quick call. Just ping me anytime on irc. I'll be using a headset.

Paul had some issues with collecting AEC logs, but we will make a quick call once he can collect logs.

This appears to be caused by the v57 update losing the setting of the DelayAgnostic and ExtendedFilter options we were using; the config structure for setting them was removed from the constructor for VoiceEngine. To set them now, you have to dig down into the audio_processing module and call SetExtraOptions() Mac (generally) works probably because the delay is low enough that it fits in the non-adjusted range of a standard filter.

This was lost due to API changes in the update to upstream v57

Comment on attachment 8919401 [details] [diff] [review] Set DelayAgnostic and ExtendedFilter options Review of attachment 8919401 [details] [diff] [review]: ----------------------------------------------------------------- lgtm

Pushed by rjesup@wgate.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/123965af3a60 Set DelayAgnostic and ExtendedFilter options r=dminor

Green Try https://treeherder.mozilla.org/#/jobs?repo=try&revision=538d01dabd30b810fa67beec734188bd2939231b jib and I had a call with a local Windows build with this patch (full debug build, very slow). I was in speakerphone mode, and the audio (per jib) was great, even at 100% volume on the speakers.

Comment on attachment 8919401 [details] [diff] [review] Set DelayAgnostic and ExtendedFilter options Approval Request Comment [Feature/Bug causing the regression]: Bug 1341285 - webrtc.org v57 update [User impact if declined]: Horrible echo if there's no OS AEC turned on (non-headset windows, most linux, Android). Many laptops with built-in audio have AEC enabled in the drivers. Mac generally is ok it seems, since the OS audio delays are smaller than the default AEC tail length (~64ms). [Is this code covered by automated tests?]: Not really (it gets turned on and used, but the tests can't verify much about echo). [Has the fix been verified in Nightly?]: Yes, manually by jib and I. [Needs manual test from QE? If yes, steps to reproduce]: Yes, would be nice - with one person on headset, and the other using laptop mic on windows with AEC in the driver disabled, have a call. before this patch it would produce horrible echo (heard by person on headset). There should be minimal/no echo with the patch, and similar to fx 55. [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: passes down a config param to the new API point to set it; same config we used to set in "new VoiceEngine(mConfig)" [String changes made/needed]: none

Comment on attachment 8919401 [details] [diff] [review] Set DelayAgnostic and ExtendedFilter options AEC is a must, Beta57+

I’m unable to reproduce the initial issue using 3 machines (Dell XPS 12 which did not had the option to turn off AEC, HP ProBook 470 G3 (17'') which did not had the option to turn off AEC and another PC with AMD FX-8320 3.50 GHz that did had the option to turn off “All enhancements”) and the link provided in comment 0. I also tried calls between those machines and using AppRTC service but without success. Marco can you please verify that this issue is fixed on 58.0 RC as well?

Verified.