+webrtc for echo cancellation; webaudio isn't involved echo cancellation.

Tested the issue on Android and unable to reproduce this issue. i.e; Not observing any difference on clicking Make tone 

Steps followed:
1. Launched chrome , opened attached html file , opened devtools console and entered navigator.mediaDevices.getUserMedia({audio: {echoCancellation: {exact: false}}})
2. Now on enabling or disabling echo suppression and clicking on Make tone no difference is seen

Chrome versions tested:
67.0.3396.87(Stable), 69.0.3501.0(canary)

OS:
Android 8.0

Android Devices:
Samsung s9

mossblaser@: Please let us know if we miss anything? If possible please provide us a screencast on reproducing the issue.This would help in better triaging.
 
Thanks!

Hello there, thanks for looking into this and appologies for the poor level of detail in my initial report.

Here is a video demonstrating the bug:

https://www.youtube.com/watch?v=GJuVDlfoG9s

The steps followed were:

1. Load web page on phone along with another nearby device.
2. Observe that speech causes spectrogram on device to move.
3. Observe that playing 'play tone' on the nearby device results in a peak being seen in the spectrogram.
4. Observe that playing the same tone using the device itself results in the spectrogram not showing the tone -- less 'blips' at the onset and end of the tone (indicative of echo cancellation or some other filtering)
5. Repeat steps with mobile firefox and observe the same effect does not occur (i.e. the tone played by the phone *does* register on the phone's spectrogram, albeit distorted and loud due to high playback level).

Note: In all stages above, echo cancellation was explicitly requested to be turned off by the web page (using the getUserMedia API). Explicitly enabling it (using the button -- not used in the video) causes firefox to throw an exception that it doesn't support it while chrome mobile just returns silence.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Most likely, what happens here is that the WebRTC-based AEC is disabled as requested but the device enables its internal (built-in) AEC implicitly instead (and it affects the frequency response). I don't think that WebRTC in Chrome on Android is fully up to par with the desktop platforms in this area and my guess is that we do not have resources to fix it any near future.

> the device enables its internal (built-in) AEC implicitly instead [...] we do not have resources to fix it any near future

If I understand correctly, this isn't mandatory in the underlying API provided by Android. (e.g. Firefox on Android doesn't enable this). Could this flag be passed through without significant changes to WebRTC on Android?

[Triage] Setting to assigned since it has an owner.

 Issue 878811  has been merged into this issue.

Issue 897881 has been merged into this issue.

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

commit ed1c3ea32c760d88d26c7723cb942329c9c23e88
Author: henrika <henrika@chromium.org>
Date: Wed Oct 31 15:41:57 2018

Improves audio input quality for WebRTC on Android

Summary:

- getUserMedia({audio: {echoCancellation: {exact: false}}}) =>
  - Adds support for "clean mode" without using any input effects on Android
  - Avoid switching to COMM mode
- Removes usage of AEC white list for Android
- Removes spam log messages
- Extends logging of audio parameters in audio streams

Bug:  866390 
Tbr: dalecurtis@chromium.org
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I45beca7e37c380826cff15ff917233e8379986cb
Reviewed-on: https://chromium-review.googlesource.com/c/1304516
Commit-Queue: Henrik Andreasson <henrika@chromium.org>
Reviewed-by: Oskar Sundbom <ossu@chromium.org>
Reviewed-by: Max Morin <maxmorin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604264}
[modify] https://crrev.com/ed1c3ea32c760d88d26c7723cb942329c9c23e88/content/renderer/media/stream/local_media_stream_audio_source.cc
[modify] https://crrev.com/ed1c3ea32c760d88d26c7723cb942329c9c23e88/content/renderer/media/stream/processed_local_audio_source.cc
[modify] https://crrev.com/ed1c3ea32c760d88d26c7723cb942329c9c23e88/media/audio/android/audio_manager_android.cc
[modify] https://crrev.com/ed1c3ea32c760d88d26c7723cb942329c9c23e88/media/audio/android/audio_record_input.cc
[modify] https://crrev.com/ed1c3ea32c760d88d26c7723cb942329c9c23e88/media/audio/android/opensles_input.cc
[modify] https://crrev.com/ed1c3ea32c760d88d26c7723cb942329c9c23e88/media/audio/android/opensles_input.h
[modify] https://crrev.com/ed1c3ea32c760d88d26c7723cb942329c9c23e88/media/base/android/java/src/org/chromium/media/AudioManagerAndroid.java

Should now be fixed. Can be verified in the next Chrome Canary on Android.

Confirmed that the change now exists in Chrome Canary 72.0.3597.0 on Android.

 Issue 869047  has been merged into this issue.