1544997 - Playback often locks up when disconnecting bluetooth headphones

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P2)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

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 1

[Michael Froman [:mjf]]

Paul, any thoughts here?

Comment 2

[Paul Adenot (:padenot)]

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

[:gerard-majax]

I think it's QC35 II. But I don't have Windows.

Comment 4

[Paul Adenot (:padenot)]

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

[:gerard-majax]

How urgent is this? I'm currently not in shape to travel to the office.

Comment 6

[Paul Adenot (:padenot)]

I'll find another way don't worry.

Comment 7

[Alex Chronopoulos [:achronop]]

As I said in IRC I don't have the headset. Clearing the NI.

Comment 8

[C.M.Chang[:chunmin]]

Unfortunately, I don't have QC35 II either. Maybe I'll have a chance to look into it after black Friday.

Comment 9

[Matthew Gregan [:kinetik]]

No QC35II here, sorry. Only the old QC25 wired.

Comment 10

[Nils Ohlmeier [:drno]]

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.

Comment 11

[Nils Ohlmeier [:drno]]

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

[Daniel Kolsis]

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:

1. Connect a working Bluetooth headset (in my case Tao-Tronics TT-BH046)
2. Open YouTube and play any video
3. 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.

Comment 13

[Matthew Gregan [:kinetik]]

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

[Paul Adenot (:padenot)]

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.

Comment 15

[Matthew Gregan [:kinetik]]

Attachment: Bug 1544997 - Propogate cubeb stream error to AudioSink to handle loss of audio device. r?padenot

Comment 16

[Matthew Gregan [:kinetik]]

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

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3fbc1456c6d2
Propogate cubeb stream error to AudioSink to handle loss of audio device.  r=padenot

Comment 18

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/3fbc1456c6d2