A few corrections:

1. Since DUT (Win7/Mac) hears the echo, the echo canceler fails at the CrOS end; updating the OS version to CrOS
2. DUT user hears echo at step (3) in the repro steps (before the double-talk)

srcv@ - do you know from your records when the last successful AEC test was done on the Leon? At least for M51, I'd like to know if this is device specific, or if it affects all CrOS devices.

Last known good build for AEC test on device Leon is M51 dev 51.0.2704.15 / 8172.6.0 dev build. 

Tested apprtc calls on device Leon with M50 stable build(50.0.2661.103 / 7978.74.0). No echo was heard. 

This appears to be a regression from M51 dev build to M51 beta build

This issue is so far observed only on device Leon with M51 51.0.2704.42 / 8172.28.0 beta

Chromium diff between 51.0.2704.15 and 51.0.2704.42:
https://chromium.googlesource.com/chromium/src/+log/51.0.2704.15..51.0.2704.42?pretty=fuller&n=10000

In that diff, I see one change that might be related to AEC:
https://codereview.chromium.org/1933603002

And here's the WebRTC DEPS diff between those same Chrome versions:
https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+log/2c769e1dc42062785cb95f5862f1e59ad1b60389..28632ca5406f66fae30a62c9327ac80a922982a1?pretty=fuller&n=10000

I see at least one change possibly related to AEC:
https://codereview.webrtc.org/1924363002 

srcv@ - how consistently are you able to reproduce the failing AEC on the Leon with 51.0.2704.42 / 8172.28.0?

We were able to reproduce this issue on chrome device Leon and Mac with builds mentioned in initial bug report 
Leon : 51.0.2704.42 / 8172.28.0 beta
Mac : M52 Canary 52.0.2730.0

This issue is not observed on device Leon with latest M52 52.0.2734.0 / 8316.0.0 dev build. 

I do hear the faint residual echo in the leon-side recording, starting about 38 seconds into the file.

I do not think that the AEC-related CLs you point out in #7 are to blame. The Chrome CL is a command line switch that is default off, and the WebRTC CL is a new AEC tuning which is only activated by said switch.

peah@, can you look at the leon recording and tell if this is a known issue?

I also listened to the recording and it is definitely too much echo for it to be ok. It is hard to tell whether this is a regression or not though from only this recording and at least we need recordings from both versions of Chrome to be able to tell anything regarding that.

The code in the listed CLs should be inactive by default (unless explicitly activated using a Chrome command-line flag) and therefore I strongly doubt that those CLs are causing this issue.


  

srcv@ and srnarayanan@ - can you get a few more recordings from both sides, or at least the Leon, using the same version of ChromeOS and Chrome that you mentioned in the original bug report? To help with further analysis, please start the audio recording *before* the call is fully established.

Retested apprtc calls on device Leon and Mac with builds mentioned in initial bug report. Echo heard from Mac when Mac user was telling numbers 34-41

Leon  : M51 beta (51.0.2704.42 / 8172.28.0)
Mac   : 10.11.5 Chrome M52 Canary (52.0.2730.0)

AEC dump from device Leon and Mac:
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/611187/

Oh, so now the echoing endpoint changed from the Leon device to the Mac? We have seen problems with glitches on M52 for Mac recently.

peah@, can you verify if this seems similar to your previous observations on Mac M52?

As I interpret comment #12, the echo is being generated on the Leon device, and that is also what I see in the recordings.

This is a very good recording, with an echo that is reproducible and not solved any of the most recent AEC updates in WebRTC.

I will need to analyze it in a more detailed manner in order to find out what goes wrong.

To confirm on #13 and #14 - the Mac user heard the echo, so the echo was generated from the Leon device.

I think this is identical to https://bugs.chromium.org/p/webrtc/issues/detail?id=5919.  
As far as I can see, the issue is caused by AEC linear filter divergence during the doubletalk section, and due to the poor performance when operating on a headset scenario the AEC fails to recover from the divergence.