Issue metadata
Sign in to add a comment
|
HTMLMediaElement.setSinkId() resolves its promise but audio still outputs to default device
Reported by
mike.j.s...@gmail.com,
Jun 6 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3074.0 Safari/537.36 Steps to reproduce the problem: Apologies for not having a reduced test case. I'll do my best to explain my case. My application plays sounds of different kinds through two audio devices. I have a USB speaker that my application routes certain audio to, and the default speaker that receives another type of audio. Since the `ondevicechange` event doesn't support output-only devices, I have some backend code that notifies my application via websocket that the USB speaker has been plugged in. This kicks off device enumeration, using setSinkId to route the correct audio to the USB speaker. The application blocks calling play() on the HTMLMediaElement object until the promise returned from setSinkId resolves so that the output device can be ready. Most of the time this works really well. Sometimes, however, a call to play a sound will come at just the right time as the USB speaker is being plugged in. In this case, device enumeration happens, and the promise from setSinkId gets resolved, but the audio gets sent to the default audio device. If the call to play() comes a second or so after the promise gets resolved however, the output gets directed to the correct sink and everything is fine. Is that promise not supposed to resolve until the audio is being directed to the right output, or does it simply resolve when the sinkId gets set in memory? Thanks! What is the expected behavior? What went wrong? The promise returned from setSinkId resolves before connecting audio output to proper device. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 60.0.3074.0 Channel: dev OS Version: OS X 10.12.5 Flash Version:
,
Jun 9 2017
Thanks for the report. I'll look into it, but it might take some time to fix this issue, especially without reliable reproduction instructions. I can confirm that the promise gets resolved only after the device is actually switched. Are you seeing the problem only when plugging/unplugging devices? If the problem is that the promise is resolved before the actual device change you should see the problem also when devices are not being plugged or unplugged. Have you confirmed that the sinkId field of the media element that plays the sound contains the ID of the USB device and not the ID of the default device (which has both "default" and hex-string IDs? Perhaps your application is choosing the hex ID for the default device instead of the ID for the USB device because it is performing the operation before the USB device is actually recognized by the system.
,
Jun 12 2017
,
Jun 12 2017
I have confirmed that the sinkId is being set to the correct hex-string ID. Only noticed the problem during plug/unplug cycles. Any other time we haven't noticed since we don't try to immediately play audio except for this case. I will try again to devise a test case or some reproduction instructions. Thanks for the reply!
,
Jun 12 2017
Thank you for providing more feedback. Adding requester "guidou@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 19 2017
,
Jun 20 2017
mike.j.santo@: I think you are hitting bug 697877. This bug consists in calling setSinkId(), which switches the device. Then remove the device and audio switches to the default device (sinkId field does not change). Then you replug the device and audio keeps playing on the default device (sinkId does not change).
,
Sep 10
mike.j.santo@:note, however, that the devicechange event for output-only devices is now supported on Mac.
,
Sep 10
,
Sep 10
guidou@: Thanks for the update. The issue you described in comment #7 definitely sounds like what I was running into. I can start watching the referenced bug if you would like to close this one. Is the output-only devicechange event functional in Linux environments? Thanks again
,
Sep 10
On Linux, if you physically plug or unplug an output-only device the devicechange event is fired. However, the event is not fired if you merely disable/enable a device using PulseAudio tools or just change the default device.
,
Sep 10
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by beccahughes@chromium.org
, Jun 9 2017Owner: guidou@chromium.org