While watching a streaming video from Amazon.com using Nightly 50 on OS X 10.11 latest, if the system sound output device is switched, for example, from Line Out to Headphones, the sound doesn't switch and continues to play on Line Out. This works correctly if Silverlight is used instead. (Testing this by disabling DRM playback in the preferences and allowing Silverlight to be used.) The same video on Chrome with Widevine works. A quick way to switch the system sound output device is to option-click on the speaker icon. See screenshot. A workaround seems to be jumping forward or backwards to a different place in the video. In my tests, that caused the video to switch to the correct sound output device after it has been changed.

Paul, Matthew -- How much work would be required to fix this?

This work has already happened on windows. I believe the osx version can be modeled from the Windows code. I'd say two weeks.

this is not isolated to widevine. plain youtube shows the same problem. the audio device is only changing once the current video completes.

this used to work fine btw...

This was regressed by https://github.com/kinetiknz/cubeb/commit/6b2c610ec860d1859d206d66327c952e9d4b0316 which landed in bug 1251502.

Matthew -- Both Padenot and Achronop are out on PTO for the next 2 weeks. Is this something you can look at, or do I need to find someone else?

Sure thing.

Before bug 1251502, we used the DefaultOutputUnit (kAudioUnitSubType_DefaultOutput) which uses whichever output is selected in the Sound->Output preferences and changes automatically as this preference changes. After bug 1251502, we use the AudioDeviceOutput (kAudioUnitSubType_HALOutput) which requires specifying a device. Note that using AudioDeviceOutput is essential for capturing input; it's not possible to capture input from DefaultOutputUnit, which is why this change was made. If cubeb_stream_init wasn't passed a specific device (which is the case for regular media playback), we'd query for the default and start with the same value DefaultOutputUnit might've used but the output would no longer follow preference changes. Fixing this directly would require the work Paul alludes to in comment 2. A quicker fix is to use the DefaultOutputUnit in the situation where we are creating an output stream and cubeb_stream_init was not passed a specific device to use. This restores the pre-bug 1251502 behaviour for regular media playback streams without affecting capture and full-duplex streams.

r? jesup since the usual suspects are unavailable.

Comment on attachment 8779966 [details] patch v0 I added a note in github: the "if device == NULL" is now inside "if device != NULL || is_input"; so if it's NULL, and no input, everything gets skipped - no set property at all. I suspect this isn't intended. Perhaps moving the "if device == NULL" part out of the new if is the right thing to do?

(In reply to Randell Jesup [:jesup] from comment #10) > Comment on attachment 8779966 [details] > patch v0 > > I added a note in github: the "if device == NULL" is now inside "if device > != NULL || is_input"; so if it's NULL, and no input, everything gets skipped > - no set property at all. I suspect this isn't intended. Perhaps moving > the "if device == NULL" part out of the new if is the right thing to do? It is intended, it's invalid to set those properties on the DefaultOutputUnit.

Comment on attachment 8779966 [details] patch v0 In that case, r+!

Too late for 48

What should we do to land this? Normally it would be import the lib, but I don't know what might else come along, especially for aurora/beta. My suggestion is to land point-patches in firefox for aurora and beta (or at least for beta), and do an import for Nightly (maybe aurora). Thanks!

(In reply to Matthew Gregan [:kinetik] from comment #9) > Created attachment 8779966 [details] > patch v0 > > r? jesup since the usual suspects are unavailable. The patch works for me.

(In reply to Randell Jesup [:jesup] from comment #14) > What should we do to land this? Normally it would be import the lib, but I > don't know what might else come along, especially for aurora/beta. My > suggestion is to land point-patches in firefox for aurora and beta (or at > least for beta), and do an import for Nightly (maybe aurora). Thanks! We're actually in a tricky position, because importing the library is blocked on bug 1286041 after merging a fix for that bug and then having ASAN reveal a bug. So I'll prepare a standalone patch for this fix for all branches.

Carrying forward r+

Carrying forward r+

Pushed by mgregan@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/2e6551eb6c8e Use DefaultOutputUnit as the default output device. r=jesup

Comment on attachment 8780953 [details] [diff] [review] patch for central and aurora Approval Request Comment [Feature/regressing bug #]: bug 1251502 [User impact if declined]: Gecko will not automatically follow the default audio output device on OS X if it is switched during playback [Describe test coverage new/current, TreeHerder]: tested locally, not covered by automated tests [Risks and why]: low risk, this reverts the behaviour of the default output device to the pre-bug 1251502 state; if this change causes any regressions they'd likely be in the full-duplex/capture case, which is not yet enabled outside of Nightly for OS X (afaik) [String/UUID change made/needed]: none

Comment on attachment 8780954 [details] [diff] [review] patch for beta Approval Request Comment [Feature/regressing bug #]: bug 1251502 [User impact if declined]: Gecko will not automatically follow the default audio output device on OS X if it is switched during playback [Describe test coverage new/current, TreeHerder]: tested locally, not covered by automated tests [Risks and why]: low risk, this reverts the behaviour of the default output device to the pre-bug 1251502 state; if this change causes any regressions they'd likely be in the full-duplex/capture case, which is not yet enabled outside of Nightly for OS X (afaik) [String/UUID change made/needed]: none

Comment on attachment 8780953 [details] [diff] [review] patch for central and aurora Recent regression since 48, we should uplift to Aurora50.

Comment on attachment 8780954 [details] [diff] [review] patch for beta I just ran into this problem twice today on 48. And it sounds like the risk of causing more regressions is low. Let's uplift to beta!

This is VERIFIED FIXED on Mac OS X 10.11 for the following builds: - Firefox RC 49.0 build 2 (id: 20160907153016) - Firefox DevEdition 50.0a2 (id: 20160909004004) - Firefox Nightly 51.0a1 (id: 20160909030428)