Closed Bug 1544997 Opened 3 years ago Closed 3 years ago

Playback often locks up when disconnecting bluetooth headphones


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




Tracking Status
firefox71 --- fixed


(Reporter: cpearce, Assigned: kinetik)


(Regressed 1 open bug)



(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.

Paul, any thoughts here?

Flags: needinfo?(padenot)
Priority: -- → P2

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).

Flags: needinfo?(padenot)
Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(kinetik)
Flags: needinfo?(jyavenard)
Flags: needinfo?(cchang)
Flags: needinfo?(achronop)

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

Flags: needinfo?(lissyx+mozillians)

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.

Flags: needinfo?(lissyx+mozillians)

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

Flags: needinfo?(lissyx+mozillians)

I'll find another way don't worry.

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

Flags: needinfo?(achronop)

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

Flags: needinfo?(cchang)

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

Flags: needinfo?(kinetik)

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.

Flags: needinfo?(jyavenard)

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?!

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.

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.

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: nobody → 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.

Pushed by
Propogate cubeb stream error to AudioSink to handle loss of audio device.  r=padenot
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1585843
Regressions: 1678846
You need to log in before you can comment on or make changes to this bug.