I haven't been able to confirm this because I don't have 2 audio output devices, although I suspect the description is accurate.

When I switch audio output devices (headphones -> "line out"), Chrome continues to play audio on headphones. Safari becomes silent (presumably because i have nothing conencted to line out). 

Are you switching via Audio MIDI Setup or some other way? Are you changing the default device or just changing the device? I think today we only listen for default device changes:

https://code.google.com/p/chromium/codesearch#chromium/src/media/audio/mac/audio_device_listener_mac.h

When the issue first occurred it was after an automatic switch performed by OS X after a bluetooth device was powered on and connected. When I tried to manually switch back and forth via the sound preferences pane (also OS X), the problem remained.

I can confirm I get this with the following steps on my MacBook Pro:

0.1) Plug in HDMI cable to my TV, set default audio out to HDMI (Samsung).
0.2) Unplug HDMI cable. (default audio switches back to internal speakers)
1) Plug in headphones and start watching a YouTube video.
Audio plays through headphones.
2) Plug in HDMI cable.
Other system audio plays through HDMI to TV.
YouTube video continues playing audio through headphones.

Btw this appears to be a regression. I didn't start having this problem until the last few weeks.

Okay I've confirmed I can get reproduce this bug without plugging/unplugging the cable as follows:

1) Plug in HDMI cable to my TV.
2) Play sound in Chrome. (I've tested both YouTube videos and Facebook videos, so it's not YouTube-specific)
3) System Preferences -> Sound -> Output -> Change the output from Internal Speakers to HDMI or vice versa.
Expected behavior: Audio switches in Chrome.
Actual behavior: Audio in Chrome continues playing through original output.

I can't even find a reliable immediate workaround. Even if I open a new window and play in that, it often keeps playing through the old output... though EVENTUALLY after several seconds it seems to eventually switch.

This is a pretty annoying bug if you often use HDMI to TV for video...

Btw I'm running 47.0.2526.58 beta

Actually on my work MacBook Pro running both slightly older and then slightly newer version of Chrome beta, I could NOT reproduce. I have no idea what the difference is…  Any ideas what I could look for?

Only thing I can think of is that I have Premiere Pro 5.5 on my personal laptop, and it adds a virtual output device called "Premiere Pro 5.5" labeled as "Aggregate device". I'm not using it, but maybe that's interacting somehow anyway?

<OP Here> 

I've managed to "fix" the problem by shutting down and then restarting chrome. 

The issue therefore seems to be that chrome subordinates the audio output to that of the system only upon startup.

A possible solution would be to replicate the startup behavior for chrome listening for a change in audio output on a more continuous basis.

We use the default device as told to us by OSX and listen for any changes. It's possible something has broken in recent versions. 

Is there a particular version of Chrome where this worked as expected?

It works for me today on 10.10.5 with 47.0.2526.73 beta, but appears to be broken on canary.

Ah, this is due to AudioOutputDevices now being created with kDefaultDeviceId instead of an empty string. The AudioManagerBase code did not identify this as a default device so stuffed "default" into the reuse map.

guidou@ I think this occurs because of the new AudioOutputDeviceEnumerator, I've put together a patch. Please review:

https://codereview.chromium.org/1480523004/

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

commit 6543b17d2aa62107125c34ec2550fd46181c316e
Author: dalecurtis <dalecurtis@chromium.org>
Date: Thu Nov 26 13:02:48 2015

Ensure both default audio device IDs are handled for creation.

With the introduction of the AudioOutputDeviceEnumerator we started
creating AudioOutputControllers with kDefaultDeviceId, but the proxy
creation code did not merge these cases correctly -- so streams
which should have been default were stuck on a single device.

This adds a test for this behavior, though it unfortunately relies
on some internal AudioManager details -- we've seen similar bugs
like this in the past, so its clear we need something.

BUG=557620
TEST=switched headphones works, new unittest.

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

Cr-Commit-Position: refs/heads/master@{#361875}

[modify] http://crrev.com/6543b17d2aa62107125c34ec2550fd46181c316e/media/audio/audio_manager_base.cc
[modify] http://crrev.com/6543b17d2aa62107125c34ec2550fd46181c316e/media/audio/audio_manager_unittest.cc
[modify] http://crrev.com/6543b17d2aa62107125c34ec2550fd46181c316e/media/audio/audio_output_proxy.h

kolos@ why did you mark this as Cr-Privacy? Feel free to reach out internally if I'm missing something.

Congrats your change is auto-approved for M48 (branch: 2564)

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

commit e1dbf162c1c043f4bb6f0bf77d99076837da33c5
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Nov 30 19:47:34 2015

Merge M48: "Ensure both default audio device IDs are handled for creation."

With the introduction of the AudioOutputDeviceEnumerator we started
creating AudioOutputControllers with kDefaultDeviceId, but the proxy
creation code did not merge these cases correctly -- so streams
which should have been default were stuck on a single device.

This adds a test for this behavior, though it unfortunately relies
on some internal AudioManager details -- we've seen similar bugs
like this in the past, so its clear we need something.

BUG=557620
TEST=switched headphones works, new unittest.

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

Cr-Commit-Position: refs/heads/master@{#361875}
(cherry picked from commit 6543b17d2aa62107125c34ec2550fd46181c316e)

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

Cr-Commit-Position: refs/branch-heads/2564@{#163}
Cr-Branched-From: 1283eca15bd9f772387f75241576cde7bdec7f54-refs/heads/master@{#359700}

[modify] http://crrev.com/e1dbf162c1c043f4bb6f0bf77d99076837da33c5/media/audio/audio_manager_base.cc
[modify] http://crrev.com/e1dbf162c1c043f4bb6f0bf77d99076837da33c5/media/audio/audio_manager_unittest.cc
[modify] http://crrev.com/e1dbf162c1c043f4bb6f0bf77d99076837da33c5/media/audio/audio_output_proxy.h

Should be fixed on Canary and also on the next M48 dev/beta update.  Please let me know if you still see this issue on Canary or M47.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/e1dbf162c1c043f4bb6f0bf77d99076837da33c5

commit e1dbf162c1c043f4bb6f0bf77d99076837da33c5
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Nov 30 19:47:34 2015

Chrome says it is up to date but this problem is still occurring for me.  I have version 47.0.2526.80 (64-bit) on OSX El Capitan.

 Issue 572012  has been merged into this issue.

I can still reproduce this on Chrome 47.0.2526.111 (64-bit) Mac OS X El Capitan.

I'm still able to reproduce this issue on Version 48.0.2564.97 (64-bit) el-Capitan

We still have users in the field reporting this on El Capitan too.

The user we're seeing who is still encountering this is using Chrome 49.0.2623.75 & OS X OSX 10.11.3 (64-bit).

I'm reliably getting this error using 55.0.2883.95 (64-bit) on Sierra 10.12.2 (16C67)
I'm using a mac mini outputting on hdmi to a receiver.

When the receiver switches from my projector to my tv, the default device switches to the internal speakers, then back to the hdmi output.

Chrome gets stuck on the internal speakers and won't make any further changes (even when the default device is manually switched).

Opening a new tab in chrome, or restarting chrome will switch to the new default device, but I haven't found any way to get the old tab to switch to the new default.

I'm working on an app myself which registers for the device change. I'm using the same flags  to register for change notifications and I am receiving them ok.
https://cs.chromium.org/chromium/src/media/audio/mac/audio_device_listener_mac.cc

I'm happy to run a debug build or do any tests that would help.


On a possibly related note; I saw the following post on stack overflow which details what they describe as a mandatory step which I can't see in the chromium code.
https://stackoverflow.com/questions/9674666/default-audio-output-getting-device-changed-notification-coreaudio-mac-os-x

Reopening since users are still seeing this. How can we evaluate if the M48-era fix actually worked?

some logging seems like the obvious first step. 
The questions are:
1) is the system change being detected
2) is chrome doing the right thing
if someone can add some logging and build a test build, I'm happy to run and test. I have the advantage of a reproducible error situation.

=>olka for triage since her team has worked on this area the most lately. I suspect this is related to the mixing work.

dalecurtis@: default device switch is handled on browser side entirely, this should not be related to mixing.

Sorry I was including maxmorin@'s mojo work in that statement. In any case please take a look. Thanks!

Yes, sure - doing that.

grunell@ could you PTAL at this since you are our main Mac person now?

I tested with a YouTube video, started Chrome 59.0.3071.36 with only built-in Mic on a Macbook Pro, OS X 10.12.4. Plugged in another device via USB (Scarlett 6i6), audio switched to that device. I could switch back and forth in system settings. I also tested A TV via HDMI, works well that too.

Can someone still reproduce this?

just tested on my mac mini again.
Sierra 10.12.4 (16E195)
Chrome 58.0.3029.110 (64-bit)

I can still reliably reproduce the issue.

mac mini connected to receiver by hdmi
receiver connected to tv (LG tv)

0) open youtube
1) play a video
sound comes out through receiver
audio & midi devices shows hdmi output (LG TV)
2) turn off receiver
video still passes through to tv, but sound reverts to internal speakers
audio & midi devices shows same hdmi output (LG TV)
3) turn on receiver
audio remains on internal speakers
4) close chrome tab
5) open new tab and open youtube
audo plays through receiver

when switching the device which is connected to the receiver, I sometimes get the same problem, but it is intermittent.

meanwhile - if you install my app AV Rules, then it does fix the problem
(e.g. after step #3, the sound switches back to the receiver)
http://hobbyistsoftware.com/avrules

rob.jonson@: thanks for the repro steps. It's somewhat different from the original report and for example comment #4. I'll see if I can get hold of a receiver to test with. Can you repro without the receiver in between? Could you also try Chrome Canary to see if it persists with the latest version?

Others who have gotten this before: can any of you still repro this?

rob.jonson@: Also, if you have a chance to test the same setup but with Windows, Linux or ChromeOS that would be great.

ok - so testing without the receiver, the result is actually a bit odd

1) mac mini plugged directly into oldish LG tv via HDMI
2) play youtube
sound comes out of TV
3) turn off TV and wait a bit
no sound
4) turn on TV
as the TV turns on, (whilst powering on, but before screen is active) the sound switches to the mac internal speaker and stays there
5) close youtube tab
6) open new tab
sound plays through TV

so, it seems that the mac mini doesn't switch the audio output until it the output is live but (presumably) invalid in some way

testing with VLC gives the same result, except that with VLC, the sound only plays on the internal speaker for a fraction of a second before switching back to the TV (after step 4)

testing with chrome canary: same result as comment 44

I can test chrome os and probably windows next week if that is necessary - let me know.

Removing ReleaseBlock-Stable, it's obviously obsolete. One fix was done and merged to M48. It may have solved some issue, but not all.

This looks similar to issue 697877

Thanks for the pointer Guido. Afaict this bug is not about setSinkId as issue 697877. I assume Youtube plays to the default device.