Did you file a feedback? What's the feedback subject? We'll need to see the logs in the feedback report.

How do I file feedback? Also, I don't think this is a bug that is hard to reproduce. I think this is the behavior you'll find on lots of (or all) Chromebooks...but I can still file feedback if you need it.

+Jimmy, who recently looked at similar problem

You can use alt+shift+i to file feedback. Please include issue number 761631 in the feedback comment so we can identify it.

Re #2: we really need a feedback report. Sometimes we cannot reproduce the issues reported. Also, there are too many bugs filed and we need to triage the bugs that have the logs first.

Thank you for reporting the issue.
I can reproduce this on 9592.85.0 and the latest canary.

https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_input_renderer_host.cc?type=cs&q=AudioDeviceDescription::kLoopbackWithMuteDeviceId&sq=package:chromium&l=367

It seems that this is working as intended according to the code:

    // For MEDIA_DESKTOP_AUDIO_CAPTURE, the source is selected from picker
    // window, we do not mute the source audio.


It means, casting to desktop does not mute local audio.

The related CL and issue:
https://codereview.chromium.org/2291893002
https://bugs.chromium.org/p/chromium/issues/detail?id=647801


Hi Qiang, please close this issue if you think this is intended. Thanks!

For use case where user does not want internal speaker to play sound while casting desktop, mute button is a easy workaround.

I won't be filing a feedback report since this issue has been verified. However, I would like to say that ideally the desired product behavior will be re-evaluated: I imagine that most use cases when casting would be better served without having the audio come out of both devices. You could also add an option for users to choose the behavior, defaulting to having audio only come out of the device being casted to.

It looks like the behavior is dependent on which API is used and not on which use case is in effect. The related ticket (https://bugs.chromium.org/p/chromium/issues/detail?id=647801) explicitly mentions that, when casting a tab/screen, the user likely wants the source audio muted. So this ticket I'm writing in right now is about making sure this actually happens.

The intended behavior for casting desktop is to mute local audio playback and that was the previous behavior when we shipped Media Router.  We haven't changed the constraints we pass to getUserMedia for some time, so this could be some change in constraints handling.  I'll check Windows behavior.

When using API chooseDesktopMedia and let the user choose something (a screen, or a chrome tab) to share, we do not mute the source audio playback. As we design this API for webrtc use.

When using API tabCapture or getUserMedia({video: {source:"screen"}, audio: {source: "system"}}), we mute the source audio playback. As we design this API for cast use.

Can you clarify which API do you use in your code?

Reproduced for me as well on Chrome 61.0.3163.79 for Windows.

We use the getUserMedia API (there's only one API underneath it all).  Here are the constraints we are passing.  We haven't changed this code in quite some time.  Should this use "system" instead of "desktop" for audio chromeMediaSource?

 {"audio":{"mandatory":{"chromeMediaSource":"desktop","chromeMediaSourceId":"tu0hZFsl0tMJckmsr4Kd9Q=="}},"video":{"mandatory":{"chromeMediaSource":"desktop","chromeMediaSourceId":"tu0hZFsl0tMJckmsr4Kd9Q==","minWidth":320,"minHeight":180,"maxWidth":1920,"maxHeight":1080,"minFrameRate":0,"maxFrameRate":30}}}

We've changed the constraints passed to gUM and that seems to have addressed the problem.  The fix was merged back to M61 and M62.  Please reopen if you see this happen again.