Hello!

I have a client (for a webRTC based audio communication platform) who experiences the same behavior. Only with webRTC connections, regular audio playback works as expected. This applies to the actual Chrome version only, running on Windows 10. Last M49 worked well...

Best regards
Tim

tommi@, can you take a look? This appears to be an output audio regression in M50.

Questions to the original reporter and anyone else who has hit this bug:
a) With Chrome 50, are you able to reproduce the bug with other versions of Windows (e.g. Win7, Win8.1, etc), or does this seem specific to Windows 10?
b) On machines where the problem occurs, can you see if the bug is still reproducible with the latest Canary Chrome build?

a) Unable to reproduce this on my Windows 7 machine. Will post another update as soon as I'm able to test on Windows 8.1.

b) Yes, this bug is still reproducible on Windows 10 and Chrome Canary 52.0.2725.0 (64-bit). Also, still reproducible with latest Chromium Build Rev. 391864 (Version 52.0.2726.0).

Thanks for the follow up! Tommi, please take a look when you get a chance.

srnarayanan@ - can you see if you can reproduce this bug on your Win10 machine?

Checked in both M50 Stable 50.0.2661.94 and M52 Canary 52.0.2725.0 in Win 10

I'm not able to repro the issue; In both versions of Chrome, it was using default audio device to output audio (headphones/speakers)

Deleted: in M50 stable.png 23.0 KB

	in M50 stable.png 23.0 KB View Download

I think this is the same as https://bugs.chromium.org/p/webrtc/issues/detail?id=5854

andrew@: can you check what is your default Recording device?
Your screenshot shows your default Playback device, but for WebRTC calls, Chrome by default uses the output device associated with the default microphone. On Windows, this device is reported in the "Recording" tab of the sound settings.

In M49 and early versions of M50 there was a bug that was causing Chromium to use the default Playback device for output, but the intent was to use the output device associated with the default Recording device.

I suspect that in your case, Windows automatically changed the default recording device to "Digital Audio (S/PDIF)" when it was plugged, but left the default playback device unchanged.

Hi guidou@

The only recording device I have on my machine is the "Microphone" device (see attached screenshot). As for "Digital Audio (S/PDIF)" -- it's NOT a recording device: it's listed in the "Playback" tab (please see screenshot attached to my original message). And in fact, it's not even a "real" device: yes, I can see in on the list but it does not seem to do anything.

Also, I was confused after reading this:

>> the intent was to use the output device associated with the default Recording device.

As I said, the only recording device that I have is the "Microphone". But how can I see associated output device (to which you were referring)??? I've checked all possible tabs and buttons - and yet I haven't been able to find this information.


Thanks.

Deleted: recording_devices.PNG 24.9 KB

	recording_devices.PNG 24.9 KB View Download

It seems andrews@'s sound adapter creates three output devices and a single input device, and the code in Chromium that selects the matching output device is not choosing the appropriate one. This is actually a bug.

seems we need a dump of navigator.mediaDevices.enumerateDevices() so that we can see which devices are grouped together by Chrome.

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

commit db0441537a40d29d9873fe3a7bba20394d1866cd
Author: guidou <guidou@chromium.org>
Date: Sun May 08 11:33:02 2016

Disable renderToAssociatedSink by default.

This flag was actually not working due to a bug. Once that bug was fixed, it
apparently triggered another bug in the code that selects associated sinks with
some specific audio adapters that create multiple output devices.

This is a simple temporary fix so that the original behavior is
restored while we fix the actual underlying bug.

If this fix works, it will have to be merged into beta and maybe stable.

BUG= 604523 

Review-Url: https://codereview.chromium.org/1956023003
Cr-Commit-Position: refs/heads/master@{#392275}

[modify] https://crrev.com/db0441537a40d29d9873fe3a7bba20394d1866cd/content/renderer/media/user_media_client_impl.cc
[modify] https://crrev.com/db0441537a40d29d9873fe3a7bba20394d1866cd/content/renderer/media/user_media_client_impl_unittest.cc

 Issue webrtc:5854  has been merged into this issue.

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

commit 6c62c8c4653f26933ef53ab1cac404a5db453679
Author: guidou <guidou@chromium.org>
Date: Mon May 09 08:30:17 2016

Add comment with description explaining why we are not expecting the originally intended default value in unit test.

BUG= 604523 

Review-Url: https://codereview.chromium.org/1957113002
Cr-Commit-Position: refs/heads/master@{#392290}

[modify] https://crrev.com/6c62c8c4653f26933ef53ab1cac404a5db453679/content/renderer/media/user_media_client_impl_unittest.cc

andrew@: can you try the latest Canary and see if it fixes the issue for you?

Also, can you show the output you get if you visit https://guidou.github.io/enumdemo4.html?

Good job! I've tested with the most recent Chromium build - and now everything's working as expected! 
Should I also check with Canary build? (I guess it does not really matter).


>> Also, can you show the output you get if you visit https://guidou.github.io/enumdemo4.html?

The output is a somewhat different in Chromium and last stable Chrome:


Output in Chromium (52.0.2730.0)

Devices:
1 - audioinput - default - - 2004946474
2 - audioinput - communications - - 4204737425
3 - audioinput - 37d1bb47a439f82268855996064cba91d4824bf2eab3ee2e62f4a8014009a771 - - 4081400566
4 - videoinput - a4227134b4844e7c1111b9500fea64e807a0d4ca45a338458c39f49369c5e4b8 - -
5 - audiooutput - default - - 2004946474
6 - audiooutput - communications - - 4204737425
7 - audiooutput - c3944ba478ac32e0e04a56b1d2c8ed9350cd49b5e2a73f72617a45731a275f22 - - 1548597238
8 - audiooutput - c3326208e78c4b1bb760784d1e2a508d6f871adc92d65a8996e8acc1357a88c3 - - 4116045665
9 - audiooutput - f0a0cdeb7d4799b24394d9e8faee9f27d00985013dc526bf5846aaf68ac6f164 - - 2076975109


Output in Chrome (50.0.2661.94 m):

Devices:
1 - audioinput - default - - 2004946474
2 - audioinput - communications - - 4204737425
3 - audioinput - 2bdcb73b9243c219ccff715d7257455e8e5a4ff45c1cdcce49a75cfea6447993 - - 177099680
4 - videoinput - d6a1b1c9120ac17dfa9b0f66975852558442a5063ecaaeca9359bbbd6b02ac31 - -
5 - audiooutput - default - - 2004946474
6 - audiooutput - communications - - 4204737425
7 - audiooutput - 8e4c4281bd544654ad6257360367cc166e767057286d53d4e37ee10090226cbb - - 28019665
8 - audiooutput - 3c3b2641e770f84d2edbef413a1ea4d1090383e5e86b98d4fb3d7e786aa6d84e - - 452641672
9 - audiooutput - 3d09931dcf4b809e33b497906ef5a4bd0e8910ce3abb8ac1409782397cc83d86 - - 3663870558


And also - is this request from hta@chromium.org still relevant?

>> seems we need a dump of navigator.mediaDevices.enumerateDevices() so that we can see which devices are grouped together by Chrome.

Thanks for verifying!
hta@'s requests was equivalent to mine. No need for further action.

Your change meets the bar and is auto-approved for M51 (branch: 2704)

Any chance for a merge with M50 stable?
When will M51 be released?

Thank you for the quick fix.

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

commit 859aa5a6cc983e32d64fd9a3c5f1123fd9e291b9
Author: Guido Urdaneta <guidou@chromium.org>
Date: Wed May 11 08:31:37 2016

Disable renderToAssociatedSink by default.

This flag was actually not working due to a bug. Once that bug was fixed, it
apparently triggered another bug in the code that selects associated sinks with
some specific audio adapters that create multiple output devices.

This is a simple temporary fix so that the original behavior is
restored while we fix the actual underlying bug.

If this fix works, it will have to be merged into beta and maybe stable.

BUG= 604523 

Review-Url: https://codereview.chromium.org/1956023003
Cr-Commit-Position: refs/heads/master@{#392275}
(cherry picked from commit db0441537a40d29d9873fe3a7bba20394d1866cd)

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

Cr-Commit-Position: refs/branch-heads/2704@{#494}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/859aa5a6cc983e32d64fd9a3c5f1123fd9e291b9/content/renderer/media/user_media_client_impl.cc
[modify] https://crrev.com/859aa5a6cc983e32d64fd9a3c5f1123fd9e291b9/content/renderer/media/user_media_client_impl_unittest.cc

No chance the fix will get merged into stable?

We are getting reports from users all the time. Users can't do anything to make the audio work and the fact that youtube works just make it more confusing.

We normally wait a couple of days after the fix hits the beta channel before requesting a merge to stable.

lots of reports here as well. Can the time to merge be shortened by sending cake?

[Automated comment] Request affecting a post-stable build (M50), manual review required.

 Issue 609048  has been merged into this issue.

Any update on this? We really need the fix to be rolled out soon. You can at least fix it somehow on Windows devices, on Mac you are completely powerless unless you uninstall drivers in the system, as there is no possibility to just disable an output device!

Can you help us test and verify that the fix works for you in Canary?

Note that the fix is also available in the beta channel.

I can confirm that Canary works well. I do not have any machine with Beta available at the moment. The weird part is that our app fails on Canary on Mac (Oh, snap) immediately when WebRTC connection is established (before showing the stream on-screen). On Windows it works without any problem. apprtc.appspot.com works fine on both. If I am able to reproduce&describe more exactly, I will file another bug report.

Can you send us the crash report id? (chrome://crashes)

The crash report id: 16bf17ca00000000. I have at least two more, but I suppose they are the same. It happens each time, no matter what I do. If you could look into this, it will be very much appreciated! I am going to try Beta channel today.

eduonsolutions@ is it possible to get a test/demo account for your app or a code snippet that reproduces the behavior?

eduonsolutions@: could you please try Dev as well to narrow down the issue better. Thanks.

I took a look and we're investigating it, but for Chrome overall I see only a couple of crash reports with that issue.  I.e. at the moment it looks like you're the only user that's running into it :-/

henrika@: Tried Beta, works well. Tried Dev, the same result as on Canary (crash report id da26731c00000000).

jansson@: This would be a bit complicated, as it takes two to get to the actual call (no way to bypass creating an appointment logic etc.). If we can get in touch directly, I can try to describe the differences from the out-of-the-box settings we use.

tommi@: Sad to hear that! I can only hope that there will be more until v52. I will help as much as I can to find the reason.

eduonsolutions@ it would be very useful if we could get some hints on what the code does. E.g. what getUserMedia constraints are used, how is the call setup (events, methods called upon and in which order etc) and so on.

Is it possible to solve it through email first and then get back here with a summary? I don't think someone would appreciate my flow of thoughts anyway and it is much more convenient for me to check the email...

jansson@: I have sent you an email to the address shown here, please reply if possible!

 Issue webrtc:5905  has been merged into this issue.

Reason for the crash mentioned was narrowed down to "echoCancellation: false" on my side. Can be easily reproduced by running apprtc.appspot.com with the appropriate parameters.

jansson@: Thank you for your reply, I have sent you a detailed email regarding my discovery process.

I am having the exact same issue, can't even google hangouts. The default recording is the microphone array(realtek hd audio) and default playback is speakers (realtek hd audio). There is no audio output coming on any of the web rtc platforms, this wasn't the case until few weeks ago. What caused this recently?
 

This is the output if I visit: ttps://guidou.github.io/enumdemo4.html? 


Devices:
1 - audioinput - default - - 100483debc4b2c6f626ca700f15dc12a24ab52a00bdcd2b7e1e89eec48b61367
2 - audioinput - communications - - communications
3 - audioinput - 86b9efcb4c11a3d7c1fa17d6697b5017fa07696ffaca0ec8f3fc0003c392439e - - 100483debc4b2c6f626ca700f15dc12a24ab52a00bdcd2b7e1e89eec48b61367
4 - videoinput - d9d68b7e408feb6860606546b14151889e358588e48505a314ca70954cf8fdf4 - -
5 - audiooutput - default - - 100483debc4b2c6f626ca700f15dc12a24ab52a00bdcd2b7e1e89eec48b61367
6 - audiooutput - communications - - communications
7 - audiooutput - 100483debc4b2c6f626ca700f15dc12a24ab52a00bdcd2b7e1e89eec48b61367 - - 100483debc4b2c6f626ca700f15dc12a24ab52a00bdcd2b7e1e89eec48b61367
8 - audiooutput - 11624b6db3c15373f60a0038fe1108068c4e7ad1a163df79ff00d662588f69f0 - - 11624b6db3c15373f60a0038fe1108068c4e7ad1a163df79ff00d662588f69f0

Hangouts and many other WebRTC based apps will default to using the communications device on Windows.  What device do you have configured as the communications device? (Windows audio device settings)

Any chance that ducking settings for the communications device are somehow incorrect?

I'm using latest chrome atm (62) with windows 7. This issue reproduces as well, I'm using https://pychat.org/ for testing.

Deleted: Безымянный.png 39.1 KB

	Безымянный.png 39.1 KB View Download

Chrome 62.0.3202.94. Windows 10. Similar problem.

Deleted: Untitled.jpg 57.3 KB

	Untitled.jpg 57.3 KB View Download

I filled separate issue as this issue is closed, but appears again https://bugs.chromium.org/p/chromium/issues/detail?id=791899 please star it

Please see #47: What device do you have configured as the communications device? (Windows audio device settings)