mail@ Thanks for the issue.

Unable to reproduce the issue on Mac 10.11.6 using chrome version 52.0.2743.82 with the below steps

1. Launch chrome by using Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-delay-agnostic-aec --enable-logging=stderr --v=3 --vmodule=*source*/talk/*=3 2>&1 | grep AudioOptions
2. Started the hangout video call and stopped.
3.Opened the chrome://webrtc-internals able to see message(please see attachment)
4.But not observed any message in command line

Please find the attached screen shot and confirm anything missed here.Please provide us any expected screen shot for better triaging the issue 

thanks,

Maybe it is helpful to tracking this down, I've also tested 50.0.2661.102, and found it demonstrates the above issue.

Version 49.0.2623.110 does not, instead reporting:

[8796:4020:0727/004403:INFO:webrtcvoiceengine.cc(1398)] Set voice channel options. Current options: AudioOptions {aec: true, agc: true, ns: true, hf: true, audio_jitter_buffer_max_packets: 50, audio_jitter_buffer_fast_accelerate: false, typing: true, experimental_agc: true, extended_filter_aec: true, delay_agnostic_aec: true, experimental_ns: true, }

One interesting difference is V50 and V52 report the AudioOptions as being set the moment getUserMedia is called with audio constraints, and never again after that-- while V49 reports it once a PeerConnection has been established.

Hi kavvaru,

  You need to make sure all instances of Chrome are closed, or your stderr will not get attached when you launch from the command line.

If you kill all instance of chrome and make sure that there isn't a black dot underneath the Chrome icon in your taskbar, if there is right click on it and Force Quit it.

Then run Chrome from the command line per the instructions, and it ought to pipe logging results into stderr and you can see the AudioOptions that are being applied.

Able to reproduce the issue on Mac OS 10.11.6 using chrome latest beta M52-52.0.2743.82 by following steps mentioned in the original comment. 

Bisect Information:
=====================
Good build: 50.0.2628.0 
Bad Build : 50.0.2630.0 

Unable to invoke Chromium when the flag condition is set during python bisect, so providing manual CL from omahaproxy

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/50.0.2628.0..50.0.2630.0?pretty=fuller&n=10000

From the above change log suspecting below change

Review URL: https://codereview.chromium.org/1618653004

nisse@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

I'm just curious- does this mean that full echo cancellation hasn't been enabled/implemented in Chrome since 50.0.2630.0?

I'm wondering if there are any Google Hangouts reports that confirm people have experienced issues with echo cancellation in newer versions of chrome?

Or is it just that Chrome isn't appropriately reporting that the extended_filter and delay_agnostic aec are enabled?

The reason I found this originally was attempting to determine the cause of degraded echo behavior when upgrading in my own application.

I'm worried though it may be a red herring since I would imagine this would have been found in Hangouts or other larger services a long time ago if it were causing issues.

Hi,

I think my cl is highly unlikely to cause this problem. 
You haven't tried doing a more fine-grained bisect?

hta@, are you familiar with audio constraint handling?

This is likely to be due to constraints rework, yes.

However, as long as aec is true in the arguments passed to WebRTC, echo cancellation will be on. The defaults for delay_agnostic and extended_filter have changed over time (at the moment delay agnostic is the default echo canceller), and I'm not sure whether the webrtcvoiceengine log line reflects that correctly.

I'll take a look and see if I can write some tests for this.

I must say, it's fairly convoluted determining what filters are applied when dealing with this code.

I've built a version of Chromium 52.0.2743.116 where I have directly modified third_party/webrtc/media/engine/webrtcvoiceengine.cc and set defaults to:

options.experimental_agc = rtc::Optional<bool>(true);
options.extended_filter_aec = rtc::Optional<bool>(true);
options.experimental_ns = rtc::Optional<bool>(true);

Doing this produces AudioOptions logs like were previously reported in 50.0.2628.0 and prior versions.

From what version is delay_agnostic set default?

It appears to be set false in 52.0.2743.116

hta - is there some action that should be taken?

Does this still reproduce?
I never got around to writing the tests I said I'd try to do in #9 - that seems like a good place to start for whoever picks this up. (I won't be able to).

Note - with getSettings() going in, we should be able to write code to return settings for all standardized constraints, so that we can tell whether they're off or on. Doesn't help for the non-standard ones.

Will look into this once the new constraints algorihtms are active.

Ping. Guido, are you able to verify this now?

Guido: can you give an eta when the new constraints algorithms are active and you'll look at this? 

grunell@/anatolid@: I'm aiming at M60 for this.

gUM constraints are correctly propagated.
The logs reported in the summary are showing properties set by PeerConnection, not getUserMedia. Closing as invalid.