guidou@ can you triage this bug please?
 (note that when recording with PCM, there's no encoding happening).

olka@: Can you take a look or help triage further?

joelriley@:

- For the getUserMedia/MediaRecorder case: if you then press the volume control on the Pixel 1, what volume is then affected? Do you see a Speaker icon (Media) or a Phone icon (Communication)? Can you compare with HTML.

dalecurtis@: are the getUserMedia/MediaRecorder client and the HTML media capture client using different audio input stacks in Chrome on Android? If not, one possible reason could be that the "HTML" case uses media mode and no built-in effects, while the getUserMedia/MediaRecorder uses communication mode and built-in effects (AEC, AGC etc.). AFAIK; using Audio constraint: {echoCancellation: false} will only disable the software based (WebRTC) AEC but not built-in AECs when available.

Why is it ExternalDependency?

re #5: During getUserMedia/MediaRecorder capture, volume control affects communication (I see phone icon). During HTML media capture, the volume controls are overridden and used as shutter buttons.

> Why is it ExternalDependency?

Because we were waiting for answers (comment 5). Am I misusing that status value?

Seems like performing audio capture in 'communication' mode may be the issue here. Is there a way to disable this with the API or reasonable to add the ability to disable when requesting a stream?

(I think "needs feedback" is done like this, external dependency is usually if there is a problem in 3rd party code or something)

I think I gave feedback in comment #8. Is anything else needed from me?

Henrik - could you PTAL?

I think I have a an understanding of what happens here but there is no simple solution to the problem.

joelriley@: if you can build Chrome for Android I could point to to some things you could try out to confirm my current theory.

The long story is that WebRTC in Chrome on Android is not up-to-date with the desktop version given that usage on Android is only a fraction of the usage on desktop platforms and I don't think we have resources at this stage to improve this area.

Did you try disabling the other two constraints as well? I.e. noiseSuppression and autoGainControl[1]? It definitely sounds like such processing could be involved in this case.

[1] https://www.w3.org/TR/mediacapture-streams/#media-track-constraints  

Now that I'm digging into it, I'm unsure of which constraints are implemented at which levels - there are some older, "goog" prefixed constraints as well. I'm going to CC guidou@ and hope he knows the answers to the following:

echoCancellation: false used to turn all processing off, but I'm unable to find where that happens. Are the standard noiseSuppression and autoGainControl constraints implemented? Are the old ones supported when specifying constraints the modern way?

Yes, noiseSuppression and autoGainControl are implemented.
If echoCancellation is set to off, noiseSuppression and autoGainControl are off by default too.
If echoCancellation is set to true or not set, noiseSuppression and autoGainControl are on by default.
Of course, it is possible to explicitly set noiseSuppression and autoGainControl to values different from echoCancellation.

It happens here: https://cs.chromium.org/chromium/src/content/renderer/media/stream/media_stream_constraints_util_audio.cc?q=media_stream_constraints_util_audio&sq=package:chromium&dr=C&l=479

One of the main issues here is that the said constraint does not affect the lower layer audio parts on Android which always tries to enable any available built-in AEC. Hence, software based components might be disabled, but the built-in parts (AEC, NS) are still enabled.

Issue 897881 has been merged into this issue.