Playback often locks up when disconnecting bluetooth headphones
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: cpearce, Assigned: kinetik)
References
(Regressed 1 open bug)
Details
Attachments
(1 file)
I have a new pair of Bose QC35II bluetooth headphones, and if I start a video with them connected (I tested YouTube) and turn them off during playback, often playback stops and can't be restarted. Or when I try to pause/resume YouTube, it plays for half a second, and then stops. This happens in release 63.01 and in Nightly. I'm on Windows 10 x64.
Comment 2•6 years ago
|
||
I don't have a pair of Bose QC35II, but I know this scenario works well on my Sony WHX1000mk2 and a pair of Sennheiser Momentum . I'm also testing on Windows 10 x64 (a Dell XPS15). It's not the first time Bose Bluetooth headphones cause issues however, so I'm not surprised (we have special code for them on OSX already).
I wonder if we have anybody that knows cubeb_wasapi.cpp or cubeb in general who could have a look at this (i.e., have access to a pair)? If not, I know gerard-majax has a pair (however maybe not QC35II, I think they are QC35).
Comment 3•6 years ago
|
||
I think it's QC35 II. But I don't have Windows.
Comment 4•6 years ago
|
||
If you can just bring it to the office when you have a chance it's probably enough for me to debug and write a fix.
Comment 5•6 years ago
|
||
How urgent is this? I'm currently not in shape to travel to the office.
Comment 6•6 years ago
|
||
I'll find another way don't worry.
Comment 7•6 years ago
|
||
As I said in IRC I don't have the headset. Clearing the NI.
Comment 8•6 years ago
|
||
Unfortunately, I don't have QC35 II either. Maybe I'll have a chance to look into it after black Friday.
Assignee | ||
Comment 9•6 years ago
|
||
No QC35II here, sorry. Only the old QC25 wired.
Comment 10•6 years ago
|
||
I do have QC35. Not sure if they are II or not. But I don't fall into the cubeb_wasapi.cpp or cubeb knowledge group.
Updated•6 years ago
|
Comment 11•6 years ago
|
||
So indeed my QC35 are series II as well. But pairing them with my Lenovo P50 running win10 I can not repro Chris issue at all. When I turn off the headset while watching a video I see a minimal drop of frames or tiny freezes, but always in the split second area.
I guess that means this specific to the combination of headset and laptop?!
Comment 12•6 years ago
|
||
Hello, I've managed to reproduce this on my system using a Tao-Tronics TT-BH046 headset on a Windows 10 Pro desktop PC:
Steps to reproduce:
- Connect a working Bluetooth headset (in my case Tao-Tronics TT-BH046)
- Open YouTube and play any video
- Turn off the headset while the video is playing
Expected result:
The video continues playing.
Actual result:
The video stops playing and the "loading" animation loops indefinitely. Pressing the Play/Pause button, clicking on the video frame or pressing the space bar on the keyboard will not start the video again.
Note: The actual result remains the same even if you restart the headset and attempt to play it again.
Assignee | ||
Comment 13•6 years ago
|
||
I can repro this, at least in some form -- it requires having no other audio devices enabled. Is that true for your case, Daniel (or Chris, if you remember)?
In this case, we have nothing to fall back to once the BT device is switched off (I doubt this is BT related, a USB unplug would have the same effect) and libcubeb ends up in an bad state. I suspect this is simply that the current code isn't prepared to handle the case where we switch from a working audio device to the system clock fallback - that works fine for starting new media, but for any playing media with a live cubeb_stream that loses its last usable audio device we end up stuck.
Comment 14•6 years ago
|
||
Indeed, we do have a fallback in Gecko when the MSG is using libcubeb, but I haven't seen anything in AudioStream
. I think that the state callback should be fired appropriately, that should allow us to fallback to something.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 15•6 years ago
|
||
Assignee | ||
Comment 16•6 years ago
|
||
Attached patch addresses the loss of the last usable audio output by falling back to the system (video) clock and continuing playback.
If an audio device is later readded, a currently playing stream won't automatically switch back, but it will play audio again after a pause/play cycle. AudioStream/AudioSink/MDSM aren't easily able to dynamically switch from system (video) clock back to audio clock should an audio device appear. I'm not sure it's worth solving that since pehrsons is planning to refactor the playback code to share the MSG implementation, which will give us this (already tested) functionality for free.
Comment 17•6 years ago
|
||
Comment 18•6 years ago
|
||
bugherder |
Description
•