The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/11556464a62ea14db9eee5e6c2a79a40aa1700ab

commit 11556464a62ea14db9eee5e6c2a79a40aa1700ab
Author: Per Åhgren <peah@webrtc.org>
Date: Fri Dec 22 15:42:13 2017

Enforcing a stream delay of 0 to be assumed in the AEC on Chrome OS

This CL forces the AEC2 to assume a stream delay of 0, thereby
avoiding that the incorrect stream delays reported on Chrome OS
causes echo issues.

Bug:  chromium:797274 , chromium:797272
Change-Id: I10f295c9f1d735622c55fc56be99a14c6cdd88a2
Reviewed-on: https://webrtc-review.googlesource.com/36081
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21432}
[modify] https://crrev.com/11556464a62ea14db9eee5e6c2a79a40aa1700ab/modules/audio_processing/BUILD.gn
[modify] https://crrev.com/11556464a62ea14db9eee5e6c2a79a40aa1700ab/modules/audio_processing/echo_cancellation_impl.cc
[modify] https://crrev.com/11556464a62ea14db9eee5e6c2a79a40aa1700ab/modules/audio_processing/echo_cancellation_impl.h

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/9c262749f5bbb2dc825c57468328315945a5d293

commit 9c262749f5bbb2dc825c57468328315945a5d293
Author: Per Åhgren <peah@webrtc.org>
Date: Fri Dec 22 23:39:44 2017

Merge of Enforcing a stream delay of 0 to be assumed in the AEC on Chrome OS

This CL forces the AEC2 to assume a stream delay of 0, thereby
avoiding that the incorrect stream delays reported on Chrome OS
causes echo issues.

TBR=henrik.lundin@webrtc.org
(cherry picked from commit 11556464a62ea14db9eee5e6c2a79a40aa1700ab)

Bug:  chromium:797274 , chromium:797272
Change-Id: I10f295c9f1d735622c55fc56be99a14c6cdd88a2
Reviewed-on: https://webrtc-review.googlesource.com/36081
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Original-Commit-Position: refs/heads/master@{#21432}
Reviewed-on: https://webrtc-review.googlesource.com/36221
Cr-Commit-Position: refs/branch-heads/64@{#7}
Cr-Branched-From: aede67a199ae0552074bfec4bb03cc9a6a5fba0f-refs/heads/master@{#20918}
[modify] https://crrev.com/9c262749f5bbb2dc825c57468328315945a5d293/modules/audio_processing/BUILD.gn
[modify] https://crrev.com/9c262749f5bbb2dc825c57468328315945a5d293/modules/audio_processing/echo_cancellation_impl.cc
[modify] https://crrev.com/9c262749f5bbb2dc825c57468328315945a5d293/modules/audio_processing/echo_cancellation_impl.h

To fix this we need to cherry-pick the CRAS CL
https://chromium-review.googlesource.com/818372

to M64.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Can you please list all OS's this impacts?

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/dc5904661c4c8b357e19595d80b2881db3f4a71b

commit dc5904661c4c8b357e19595d80b2881db3f4a71b
Author: Per Åhgren <peah@webrtc.org>
Date: Wed Jan 03 00:15:38 2018

Merge of Enforcing a stream delay of 0 to be assumed in the AEC on Chrome OS

This CL forces the AEC2 to assume a stream delay of 0, thereby
avoiding that the incorrect stream delays reported on Chrome OS
causes echo issues.

TBR=henrik.lundin@webrtc.org
(cherry picked from commit 11556464a62ea14db9eee5e6c2a79a40aa1700ab)

Bug:  chromium:797274 , chromium:797272
Change-Id: I10f295c9f1d735622c55fc56be99a14c6cdd88a2
Reviewed-on: https://webrtc-review.googlesource.com/36081
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Original-Commit-Position: refs/heads/master@{#21432}
Reviewed-on: https://webrtc-review.googlesource.com/36220
Cr-Commit-Position: refs/branch-heads/63@{#14}
Cr-Branched-From: bef8a5d2ca5413c680995584b8c0976852ba5f25-refs/heads/master@{#20237}
[modify] https://crrev.com/dc5904661c4c8b357e19595d80b2881db3f4a71b/modules/audio_processing/BUILD.gn
[modify] https://crrev.com/dc5904661c4c8b357e19595d80b2881db3f4a71b/modules/audio_processing/echo_cancellation_impl.cc
[modify] https://crrev.com/dc5904661c4c8b357e19595d80b2881db3f4a71b/modules/audio_processing/echo_cancellation_impl.h

Please ignore the merge request for https://chromium-review.googlesource.com/818372.

That CL only solves the reported latency on some of the boards (stable on auron-based boards).
There are other boards having incorrect reported delay.

For example, on eve, the reported round trip latency is less than measured latency by 80ms consistently.
This delay is added to latency caused by buffer level reported by driver, and is different on different boards.

We need to measure and compensate this value in CRAS to report a correct latency.
Until then, AEC can not trust the reported latency on ChromeOS.

Jimmy. Is this still targeting M64? It's late for M64.

#7 and #12 handles M63 and M64 already.

We can fix the wrong reported value in the future releases.

[Re-triage] What's the status of this bug? Has it been fixed for M65? Is P1 correct? If yes, please set a target milestone.

I'm actively investigating the latency discrepancy, but I'm afraid I don't have a good estimate for when this will be fixed at the moment. I'll update when I do.

The discrepancy of reported latency and measured latency is different on different boards.
We need a way to calibrate the delay in DSP (may be as low as few ms, or as large as 70 ms), and fix snd_pcm_delay call in the driver so it can reply a value that is as close to the measured value as possible.

I think it is impossible for M65.
So targeting M66 instead.

Issue 801404 has been merged into this issue.

louiscollard@: do you estimate this will be fixed for M66? (Asking since it's a P1.)

Not in M66. Also, we won't go back and fix all old boards because it requires efforts on every platform. I think we should fix KabyLake (like eve and soraka) and after.

Per: how urgent is this? Should this be a P2?

Done. Changed to P2.

Should this be bumped to M69?

Yes we still don't have a good plan for how to fix this properly. 

Max, is this related to your recent changes?

As far as I can see,  Issue 903213  is about Chrome misinterpreting the timestamp provided by cras and this issue is about the cras not being in agreement with the physical reality. One could easily be mistaken for the other though.

I'd say  Issue 903213  is a part of this one the way it's formulated now.

cychiang@, are there any updates on #20? Was it fixed?