This issue was fixed upstream in WebRTC: https://codereview.webrtc.org/2262203002/

The fix was rolled into chrome in https://codereview.chromium.org/2271613002.

First chrome branch to include the fix is 54.0.2838.0. It hit Canary on Windows, Mac, and Android 2016-08-24.

I'd like to get this fix merged to M53. It has been in canary channels for a couple of days.

Approving merge to M53 branch 2785 based on comment #1 and  #2. Please merge ASAP or latest before 4:00 PM PT  Monday in order to make into the desktop Stable final build cut.Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869

commit ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869
Author: henrik.lundin <henrik.lundin@webrtc.org>
Date: Mon Aug 29 07:48:09 2016

Add NetEq::FilteredCurrentDelayMs() and use it in VoiceEngine

The new method returns the current total delay (packet buffer and sync
buffer) in ms, with smoothing applied to even out short-time
fluctuations due to jitter. The packet buffer part of the delay is not
updated during DTX/CNG periods.

This CL also pipes the new metric through ACM and uses it in
VoiceEngine. It replaces the previous method of estimating the buffer
delay (where an inserted packet's RTP timestamp was compared with the
last played timestamp from NetEq). The new method works better under
periods of DTX/CNG.

Review-Url: https://codereview.webrtc.org/2262203002
Cr-Commit-Position: refs/heads/master@{#13855}
(cherry picked from commit b3f1c5d2fe00ac2201e533345f55eee220d66876)

BUG= chromium:640913 
TBR=tina.legrand@webrtc.org
NOPRESUBMIT=true
NOTRY=true

Review-Url: https://codereview.webrtc.org/2287243002
Cr-Commit-Position: refs/branch-heads/53@{#6}
Cr-Branched-From: 65f47275cbb5ad3aa5146b9e75afa9894467daff-refs/heads/master@{#13317}

[modify] https://crrev.com/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869/webrtc/modules/audio_coding/acm2/acm_receiver.cc
[modify] https://crrev.com/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869/webrtc/modules/audio_coding/acm2/acm_receiver.h
[modify] https://crrev.com/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869/webrtc/modules/audio_coding/acm2/audio_coding_module.cc
[modify] https://crrev.com/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869/webrtc/modules/audio_coding/include/audio_coding_module.h
[modify] https://crrev.com/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869/webrtc/modules/audio_coding/neteq/include/neteq.h
[modify] https://crrev.com/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869/webrtc/modules/audio_coding/neteq/neteq_impl.cc
[modify] https://crrev.com/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869/webrtc/modules/audio_coding/neteq/neteq_impl.h
[modify] https://crrev.com/ca8d4aa1838bc6ee91dc36a3402e3f08e63b6869/webrtc/voice_engine/channel.cc

Per comment #4, this is already merged to M53. So removing "Merge-Approved-53" label.

[triage] Does it make sense to add unit tests for the CL in #4?

Re #6: Yes, it makes sense. Tracked here: https://bugs.chromium.org/p/webrtc/issues/detail?id=6279.

hlundin@ - whats the expected range of googCurrentDelayMS in an apprtc call with opusdtx=true param?

Re #7 Thanks!

Re #8: with my fix, the googCurrentDelayMS value should be in the same range with and without opusdtx=true. What that range is depends very much on the network conditions. Quick test between two laptops on internal WiFi shows numbers in the range 100-200 ms. 

However, the key observation with this bug was that when endpoint A muted the mic, endpoint B would see sharp increases in googCurrentDelayMS in correlation with packet losses, and the level would not come down again until A unmuted. This should no longer be observed.

Verified in M54 Dev 54.0.2840.14. 
Established a 2 way apprtc call b/w Mac & Linux and googCurrentDelayMS value is in the same range with/without opusdtx=true param. 
Also, when I mute the mic in Mac, I do not see any packet loss or sharp increase in googCurrentDelayMS value from the Linux endpoint.

Can the owner please double check that the milestone is set correctly for this issue?

FYI, the last CL associated with this issue has been added after the M54 branch was created and before the M55 branch was created, so perhaps this issue should be marked as M55?

hlundin@, could you ptal comment #12 and reply please?

It was fixed in M54, and merged to M53. Which M-labels should be applied?