Bug report filed in the webrtc test github.
https://github.com/webrtc/testrtc/issues/272

I think the bug is related to this: https://bugs.chromium.org/p/chromium/issues/detail?id=855371

Tested the issue on chrome reported version# 68.0.3440.75 using windows-10 Surface pro with steps mentioned below:
1) Launched chrome reported version and opened New Tab page
2) Clicked on Mic icon, clicked on Allow access for microphone, and spoke youtube, able to navigate to nextpage

@Reporter: Please find the attached screencast for your reference and provide your inputs on it and let us know if this issue is specific to Huawei Matebook X Pro and try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists.

Thanks!

Deleted: 868026.mp4 1.2 MB

	868026.mp4 1.2 MB View Download

Hi, here's a google drive link for the video I just recorded. This computer has a quad microphone setup. https://drive.google.com/file/d/1cTIhK4fCWkHV5vHcljQ2eg9LNeK8zj-l/view?usp=sharing

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

Again, this bug is specific to something in the matebook x pro. Possibly the microphones. Workarounds include, using a wired or bluetooth microphone. Or use the internal quad microphones in Edge or Firefox!

As per comment#8 the issue seems to be repro on Matebook X Pro only and it is not getting reproduced from TE end as per comment#4. Hence adding harware dependency label.

Thanks.!

It would be useful to see a trace from the Developers Tools console running navigator.mediaDevices.getUserMedia({audio: true}) to have an idea of whether the issue is cause by an exception on the device, or whether the input source is simply never detected.

Possibly using appr.tc to join a call could also be a viable option to verify what happens in such a case.

Waiting for someone to join this room: https://appr.tc/r/162203304
States:     
Signaling:  have-local-offer
Gathering:  complete
Connection: new
Local:      host:1 srflx:1 relay:2
Remote:     

Stats:      
Call time:  01:10
Setup time: 0 ms

Messages:  
Error getting user media: Could not start audio source
getUserMedia error: Failed to get access to local media. Error name was NotReadableError. Continuing without sending a stream.

Version:    
gitHash:    20cdd7652d58c9cf47ef92ba0190a5505760dc05
branch:     master
time:       Fri Mar 9 17:06:42 2018 +0100

Thanks for that. My suspicion is that the driver associated to the mic is actually failing to apply the coercion to use stereo. Could you enable logs and provide an extract related to a test call using appr.tc?

Enabling logging: http://www.chromium.org/for-testers/enable-logging

Here it is. I used Canary channel so it shouldn't contain any personal info, hopefully (I'm not signed into canary, just use it for testing.)

Deleted: chrome_debug.log 1.7 MB

chrome_debug.log 1.7 MB View Download

I would say the log at line 1592 confirms the suspicion:

[5980:27768:0828/092437.626:ERROR:adm_helpers.cc(73)] Failed to query stereo recording.

The driver does not know how to record stereo, while Chrome currently does not support 4 channels. I will set crbug/453876 as a blocker to this bug. As soon as we complete the multichannel support, we will come back to this to verify that it fixes the issue.

After obtaining the device I have done some tests, and got help from henrika to determine the root-cause of the issue. It turns out that the issue is not tied to having 2 channels per se but rather to the implementation of the windows specific part of the audio stack.

The problem resides in the type used for input_format_ (https://cs.chromium.org/chromium/src/media/audio/win/audio_low_latency_input_win.h?l=222&rcl=15a90436835a78e8438127b866bccb6769325af4) and the related code. When using WAVEFORMATEX (https://msdn.microsoft.com/en-us/library/windows/desktop/dd390970(v=vs.85).aspx), the assumption is that the code treats only mono or stereo. To deal with devices with more channels, the right type to use is WAVEFORMATEXTENSIBLE (https://msdn.microsoft.com/en-us/library/windows/desktop/dd390971(v=vs.85).aspx), and as a result the code should be adjusted for that. I created a PoC just to determine if it is possible to successfully open the device, which indeed it is (crrev.com/c/1254064). The audio of this CL is however distorted so needs further work.

Hence I am removing the dependency on Issue 453876, since the device an be open when using only stereo. I am also reassigning the bug to ossu for further triaging.

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

commit 4e7696d420da6fbf39c556d0d904c2766860c9c1
Author: henrika <henrika@chromium.org>
Date: Thu Oct 25 16:55:23 2018

Adding multi-channel input support on Windows with minimal impact on all other input cases.

Focus is here to support one particular device and to adapt internally to its multi-channel
structure.

This CL adds a dependency of a channel layout called "discrete" for the input later on Windows.
It also ensures that the input device can be opened up with four channels, but these channels
are then downmixed to two channels to fit the renderer side.

Bug:  868026 
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: I2fc63802d99d9d438bdd9f8baf424b3d8cdfab65
Reviewed-on: https://chromium-review.googlesource.com/c/1268118
Commit-Queue: Henrik Andreasson <henrika@chromium.org>
Reviewed-by: Oskar Sundbom <ossu@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602760}
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/content/renderer/media/stream/processed_local_audio_source.cc
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/content/renderer/media/stream/track_audio_renderer.cc
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/media/audio/audio_manager_base.cc
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/media/audio/win/audio_low_latency_input_win.cc
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/media/audio/win/audio_low_latency_input_win.h
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/media/audio/win/audio_low_latency_input_win_unittest.cc
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/media/audio/win/core_audio_util_win.cc
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/media/audio/win/core_audio_util_win.h
[modify] https://crrev.com/4e7696d420da6fbf39c556d0d904c2766860c9c1/media/webrtc/audio_processor.cc

What chrome release is this expected to be included in? thank you everyone for helping fix this. <3

Will probably be included in M72 which will hit stable by the end of January.
But you can always try out the latest changes in Chrome Canary or see the change earlier in e.g. the Chrome dev channel.