User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20140127194636 Steps to reproduce: Set youtube.com to play videos in HTML5 instead of flash. Start playing a video through Surface Pro headphones. Unplug headphones. Actual results: Sound cuts out in headphones but doesn't switch to speakers. Plugging in headphones again doesn't restore sound in headphones. Refreshing the youtube page restores sound in headphones if they are plugged, in but not in speakers if the headphones are not plugged in. Restarting the Firefox browser with the headphones unplugged is the only way to get the youtube HTML5 player to switch to speakers and visa versa for headphones. Expected results: Sound should have switched from headphones to speakers and back.
Reverse problem: If Firefox is started with the headphones unplugged, a youtube HTML5 video will play through the speakers. After plugging in the headphones, the sound continues to play through the speakers, even after a page refresh. Restarting the browser with the headphones plugged in is the only way to get the youtube HTML5 player to play through the headphones.
Another major problem: After playing a youtube HTML5 video through the headphones and then unplugging the headphones, the Firefox process hangs after closing the browser. This prevents Firefox from being restarted. The firefox process has to be manually killed with the Task Manager.
Update: I just tested this same scenario using Internet Explorer 11. While playing a youtube video with HTML5, I could switch back and forth between headphones and speakers perfectly. So it is not a Windows 8 or Surface Pro bug. It is a Firefox bug. Please fix it. Firfefox had similar headphone/speaker issues with the flash player. I opened a previous bug for that.
I installed the Pale Moon Mozilla-based browser (v 24.5.0) and tested the above scenario again. It works fine. The browser dynamically switches between headphones and speaker while playing an HTML5 youtube video. So I'm done with Firefox until (if) they fix this bug.
This would've broken when we switched to the WASAPI in Firefox 25, so this breakage will migrate into Pale Moon when they update their source. The old API (WinMM) used to handle this for us, but now it looks like we need to do a bunch of work at the WASAPI level to detect that an endpoint has gone away (not too surprising as WASAPI is significantly lower level). Looks like registering an IMMNotificationClient to receive OnDefaultDeviceChanged notifications is what we need to do. MSDN docs here: http://msdn.microsoft.com/en-us/library/windows/desktop/dd370810%28v=vs.85%29.aspx Paul/Randel, I can't find an existing OnDefaultDeviceChanged in the tree - does WebRTC use WASAPI for capture? If so, we'll have the same sort of problem there.
I'm (slowly) working on this in a new branch: https://github.com/kinetiknz/cubeb/tree/wasapi_routing
This should be fixed by bug 698079.