2055266 - Firefox closes audio endpoint during video seeking/pausing, causing audio dropouts on Bluetooth headphones (Sennheiser Momentum 4)

Status: RESOLVED DUPLICATE of bug 2059525

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

Description

[Kajlu]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0

Steps to reproduce:

1. Connect Sennheiser Momentum 4 headphones to a Windows PC via Bluetooth.
   2.Open YouTube in Firefox and play any video.
   3.Pause the video or skip forward/backward on the timeline.
   4.Resume playback.

Actual results:

The first 1–2 seconds of audio are completely muted/cut off after seeking or resuming. The headphones temporarily disconnect from the active audio stream.

Expected results:

Audio should resume instantly without any delay, similar to Chromium-based browsers (Opera, Chrome). During video seeking or pausing, Firefox performs a complete audio stream tear-down/endpoint release instead of maintaining an active session with a silent buffer (audio padding). The aggressive power-saving/auto-mute mechanism in the Sennheiser Momentum 4 firmware reacts instantly to this lack of signal by putting the internal amplifier into micro-sleep. When playback resumes, it takes about 1000ms for the hardware to renegotiate the link and wake up.Please consider implementing continuous silent buffer streaming (audio padding) during temporary video buffering and seeking states to prevent Bluetooth hardware from dropping the connection.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alastor Wu [:alwu]]

Please try the latest Nightly, the fix from bug 2052692 now prevents audio stream from being recreated during seeking, which should help.

Comment 3

[Jim Mathies [:jimm]]

Might be related to recent seek perf work?

Comment 4

[Alastor Wu [:alwu]]

No, seek performance was landed on 154, but the issue is on 152. Could you help us capture a media profile per this instruction? Thanks!

Comment 5

[Kajlu]

https://share.firefox.dev/4flRIj4

Comment 6

[Jim Mathies [:jimm]]

Bug 2055266 Triage Analysis

Generated: 2026-07-30
Bug URL: https://bugzilla.mozilla.org/show_bug.cgi?id=2055266

Bug Information

• Summary: Firefox closes audio endpoint during video seeking/pausing, causing audio dropouts on Bluetooth headphones (Sennheiser Momentum 4)
• Reporter: [e-mail] (external, first report)
• Status: UNCONFIRMED, unassigned
• Product: Core
• Component: Audio/Video: Playback
• Created: 2026-07-15 (15 days old)
• Severity / Priority: -- / -- (both unset)
• Version: Firefox 152; Windows 11 (from UA)
• See Also: 2052692
• Security sensitive: No
• Scope profile used: media

Research Summary and Key Findings

The reporter describes a 1–2 second audio dropout after pausing, seeking, or resuming YouTube
playback with Sennheiser Momentum 4 Bluetooth headphones on Windows. Their proposed mechanism is
unusually specific and, per the code read below, substantially correct: Firefox stops the audio
endpoint rather than keeping it alive with silence, the headphone firmware's aggressive power saving
puts the amplifier into micro-sleep, and re-waking the link costs roughly a second.

The headline finding: the advice in comment 2 does not apply to this reporter's platform

:alwu pointed the reporter at 2052692
("prevents audio stream from being recreated during seeking"). That fix is real and landed, but it is
gated behind media.audio.reuse-stream-on-seek, which is true only on macOS and false
everywhere else — including Windows. The pref's own comment in
StaticPrefList.yaml
says so explicitly: "Enabled on macOS first, where the win is largest; once it proves out there it
can be turned on for other platforms."

So on this reporter's Windows machine, the seek path still destroys and recreates the cubeb stream
even on the latest Nightly. Asking them to "try the latest Nightly" as-is will produce a
no-improvement answer that tells us nothing, because the code path they need is switched off on their
OS.

Second finding: a user pause is architecturally excluded, on every platform

Even with the pref on, the keep-alive only engages for seek pauses. From
AudioSinkWrapper.cpp:352-357:

// A seek pause keeps the backend running so the following stop/start can
// reuse the stream; any other pause stops the backend.
const bool keepRunning = aReason == StopReason::Seeking &&
                         mReuseStreamOnSeek && !mAudioSink->IsErrored();

The reporter's report covers both pause/resume and seeking. The pause half is not addressed by
either landed fix on any platform, and is current intended behavior. Their feature request
(continuous silent-buffer streaming during temporary pause/buffering states) is therefore a genuinely
separate ask from the seek work, and deserves to be evaluated on its own terms — keeping an endpoint
open through an indefinite user pause has real power-consumption implications, which is presumably
why it works this way.

Third finding: the reporter's profile does not capture the bug

Comment 5 cleared :alwu's needinfo with a bare link to https://share.firefox.dev/4flRIj4 and no text.
Analyzed with profiler-cli:

Property	Value
Build	Firefox 153 release, build 20260715202819 — not Nightly
Platform	Windows 11 (build 26100), AMD Ryzen 7 5800XT, 8C/16T
Duration	10.53s, 1ms sampling, audiocallbacktracing enabled (media preset used correctly)
MOZ_LOG entries	28,736 (AudioSink, AudioSinkWrapper, cubeb, MediaFormatReader all present)

What the profile actually contains:

• No user seek and no pause/resume of any element. The single SEEKING_ACCURATE is the
  start-of-playback seek to position 0 out of DORMANT. There are no seeking/seeked events at all
  in HTMLMediaElementEvents.
• One audio stream created, never destroyed. A single CubebStreamInit →
  SyncCreateAudioSink(0) → InitializeAudioStream (initial) at T+2.93s, with Stream init successful 17 ms later. Zero cubeb_stream_destroy in the whole profile.
• The only AudioSinkWrapper::Stop (T+7.13s) is the natural ended of a loom.com video, not a
  user action.
• The captured stream is completely healthy: 755 data callbacks at 100.0/sec,
  AudioStream::DataCallback max 256 µs against a 10 ms real-time budget. No underruns, no gaps.
• The two elements playing are loom.com (:alwu's own instruction video) and
  alastor0325.github.io (:alwu's test page). Six youtube.com content processes exist but have
  zero media activity — no MediaDecoderStateMachine thread, AudioIPC Client Callback at
  0.004 ms.

The reporter appears to have recorded themselves starting playback on the linked test page while the
instruction video finished, without performing steps 3–4 of their own STR. The profile is unusable
for this bug, but it is not a wasted artifact: it confirms they can capture a correct media profile,
so a re-request is very likely to succeed.

One confound the profile reveals: 18 extensions, several of which hook media or audio — Video
DownloadHelper BETA, YouTube High Definition, YouTube To Mp3 Button, Return YouTube Dislike, an AudD
music-recognition addon, SaveFrom.net helper, Tampermonkey, uBlock Origin, Browsec VPN, User-Agent
Switcher. Worth a troubleshoot-mode check before deep investigation.

Related bugs

This is not a duplicate, but it lands in a large, well-populated cluster.

Should be marked blocking 2011679 —
[Meta] Bluetooth device related issues with audio and video (NEW, S2/P2, 23 dependencies).
2055266 is not currently in that list and belongs there.

Highest-signal siblings:

• 2008968 — Youtube video stutters when
  playing at start and seeking if a Bluetooth device is set as the output Audio (NEW, S3/P3, All).
  The most important one. Mozilla QA (:atrif, comment 6) reproduced on Firefox 152, 153.0b1 and
  154.0a1 across macOS 26, Windows 11 and Ubuntu 26 with Red Mi Buds 5 Pro, "especially when
  seeking video… This does not happen with speakers or TRS headphones." That establishes the
  Bluetooth-plus-seek problem is real, cross-platform, and not specific to Sennheiser firmware.
  Symptom framing differs (video stutter vs. audio cut), so I would keep them separate for now.
• 2055541 — YouTube Audio/Video desync with
  Bluetooth devices when pausing or skipping (VERIFIED FIXED, S3/P1, macOS, :alwu).
  regressed_by 2050845 — i.e. the
  seek-latency work already caused one Bluetooth-specific regression, found by :sky, fixed and
  verified on 154.0b3. Directly relevant precedent: this code path and Bluetooth devices interact
  badly, so flipping the pref on Windows needs Bluetooth validation, not just latency numbers.
• 1990361 — Audio cut when using the
  bluetooth headset (REOPENED, S3/P3, filed by :alwu, blocks the meta). Closest symptom match on
  file; Android QA could not reproduce, reopened on comment 3.
• 1977352 — Audio volume automatically lowers
  when pausing or seeking video on Firefox with AirPods Pro on macOS (UNCONFIRMED, S3). Same trigger
  (pause/seek), same device-side power-management theme; notably "in troubleshoot mode, the issue does
  not occur."
• 1868267 — Desynched audio channels while
  clicking play/pause with bluetooth AirPods, and
  1936931 — Video desyncs with audio after
  Youtube ads if Bluetooth headphones are used (ASSIGNED, S3/P2, Windows 11).
• 2034333 — Slow cubeb operations in the
  AudioIPC server event loop stall content-process cubeb RPC (ASSIGNED, S3/P3). Plausible amplifier
  for stream start/stop cost.

Gap worth noting: no bug exists tracking the rollout of media.audio.reuse-stream-on-seek beyond
macOS. The pref comment promises it, nothing tracks it. That follow-up is arguably the single most
valuable action to come out of this report.

Regression Timeline

Not a regression, and no regression data was offered. The reporter makes no claim that this ever
worked, ran no mozregression, and there is no regressed_by. The comparison drawn is cross-browser
(Chrome/Opera behave better), not cross-version.

The relevant timeline is the fix timeline, which is what makes the version numbers in this bug
confusing:

Date	Event
2026-07-03	2050845 FIXED — async sink create on seek resume (all platforms), clock bridging. Target: 154
2026-07-14	2052692 FIXED — reuse stream across seek, behind a macOS-only pref. Target: 154
2026-07-15	This bug filed against 152. :alwu recommends Nightly (comment 2)
2026-07-16	2055541 filed — BT desync regression from 2050845 on macOS
2026-07-24	:alwu correctly notes seek-perf work is on 154, not 152 (comment 4); reporter posts a 153 release profile
2026-07-27	2055541 verified fixed on 154.0b3

So neither seek fix is in 152 or in the 153 build the profile was captured on, and the one that
matters most for this symptom is off on Windows regardless of version.

Assessment

• Suggested Severity: S3
• Suggested Priority: P2

Assessment Reasoning

S3 fits. The impairment is real and repeats on an extremely common interaction (seek/pause on
YouTube) with extremely common hardware (Bluetooth headphones), and there is no user-side workaround
short of switching to wired audio. What holds it below S2 is the magnitude: a 1–2 second dropout on
resume, not a loss of playback or of audio altogether, and the severity is modulated by device
firmware — QA's cross-platform repro on 2008968 notes it is "not so noticeable" on Windows 11 with a
different headset. Every sibling in this cluster is rated S3, so S3 also keeps the family
self-consistent. The aggregate matters more than any single report, which is exactly what the S2/P2
meta 2011679 is for.

P2 rather than P3 because, unusually for a bug in this cluster, the machinery to fix half of it is
already written, landed, and shipping on macOS. The remaining work for the seek half is to validate
and flip media.audio.reuse-stream-on-seek on Windows, which the pref comment already contemplates.
That is cheap and high-leverage. It is not risk-free — 2055541 shows this exact code path regressing
Bluetooth A/V sync on macOS — so it needs Bluetooth-specific validation rather than just seek-latency
measurements, but that is a scheduling question, not a research question.

The pause half should be split off rather than tracked here. Keeping the endpoint alive across an
indefinite user pause is a different trade-off (power draw) from keeping it alive across a
sub-second seek, and conflating them in one bug will stall both. Not a good first bug — it spans
cubeb, WASAPI endpoint lifetime, and cross-platform pref rollout with a known regression history. The
pref-rollout follow-up is small but needs perf and Bluetooth validation, so it is not
contributor-friendly either.

Codebase Investigation

Local tree confirmed to contain all of 2050845, 2052692, and 2055541 Part 1, so the reads below
reflect post-fix mozilla-central.

Relevant Files Examined

• dom/media/mediasink/AudioSinkWrapper.cpp
  — SetPlaying (line 338), Start (392), MaybeAsyncCreateAudioSink (489), SyncCreateAudioSink
  (653), Stop (696).
• dom/media/mediasink/AudioSinkWrapper.h
  — mReuseStreamOnSeek initialized from the pref (line 38), declared const (154).
• dom/media/mediasink/AudioSink.h
  — SetStreamKeepRunning (81), PrepareForReuse, ResetForReuse.
• dom/media/mediasink/AudioSink.cpp
  — SetPlaying (396): pause/resume forwards straight to AudioStream::Pause/Resume.
• dom/media/AudioStream.cpp
  — Pause (386), Resume (421), SetKeepRunningMode (455), ShutDown (463).
• modules/libpref/init/StaticPrefList.yaml
  — media.audio.reuse-stream-on-seek (line ~14091).

Findings

1. The keep-alive is doubly gated, and Windows fails the first gate.
AudioSinkWrapper::SetPlaying (line 352) and AudioSinkWrapper::Stop (line 708) both require
aReason == StopReason::Seeking && mReuseStreamOnSeek. mReuseStreamOnSeek comes from
media.audio.reuse-stream-on-seek, which is #if defined(XP_MACOSX) → true #else → false. On
Windows both conditions collapse to false, so Stop takes the ShutDownAudioSink() branch and
SetPlaying(false) calls SetStreamKeepRunning(false).

2. Without keep-running, a pause is a real cubeb_stream_stop.
AudioStream::Pause (line 401) short-circuits to a logical-only stop only when
mKeepRunning && mCubebStarted; otherwise it falls through to the normal stop path, which stops the
cubeb/WASAPI render stream. Resume (line 435) is symmetric. This is the endpoint going idle that
the reporter's headphone firmware reacts to — so their description of the mechanism is accurate for
Windows, for both pause and seek.

3. On Windows the seek recreate is async but still a recreate.
AudioSinkWrapper::Start (line 451) routes StartType::SeekResume to MaybeAsyncCreateAudioSink
and everything else to SyncCreateAudioSink. That async path is not platform-gated, which
matches :alwu's note in 2052692 comment 0 that Windows got the full win from 2050845. But async
recreation only moves the cost off the MediaDecoderStateMachine thread — it does not stop the
endpoint from closing. That distinction is the crux of this bug: 2050845 improved the latency
metric on Windows while leaving the endpoint-closure behavior that Bluetooth firmware responds to
completely intact. A fix measured in milliseconds of seek latency cannot be expected to fix a
device-firmware wake-up penalty measured in ~1000 ms.

4. The profile corroborates the healthy-path baseline.
The one stream that was created in the profile ran 755 callbacks with no underruns and a 100 ms
initial WASAPI buffer (Buffer size is: 4410 for render at 44100 Hz, then steady 441-frame/10 ms
callbacks). Nothing anomalous in steady-state playback — consistent with the problem being confined
to the stop/start transition, not to streaming.

Suggested Investigation Areas

1. Measure media.audio.reuse-stream-on-seek=true on Windows. This is the cheapest decisive
   experiment and directly serves the rollout the pref comment promises. Validate against Bluetooth
   A/V sync, not just seek latency — 2055541
   is the cautionary precedent.
2. Decide the policy question for non-seek pause. Whether to hold the endpoint open (or feed
   silence) across a short user pause, and with what timeout before releasing it, is a product/power
   trade-off. A bounded linger — keep the endpoint alive for N hundred ms after pause, release if the
   pause persists — would address the reported symptom without holding a device awake indefinitely.
   Worth its own bug.
3. Instrument the transition rather than the steady state. Any future profile request should
   target the stop→start window specifically; steady-state callback health is already known good.
4. Cross-check against 2008968. QA has a
   reliable cross-platform repro there with hardware Mozilla already has. That is a faster path to a
   confirmed Windows repro than iterating with this reporter through their 18 extensions.

Recommended Bugzilla Actions

1. Set severity S3, priority P2.
2. Mark this bug blocking 2011679
   (Bluetooth meta) — it is missing from the 23 existing dependencies.
3. Add see_also to 2008968 and
   1990361.
4. Set platform/OS to Windows 11 (currently Unspecified/Unspecified, though the UA and profile
   both say Windows).
5. File the follow-up to validate and enable media.audio.reuse-stream-on-seek on Windows/Linux.
6. Re-needinfo the reporter with the corrected instructions below.

Proposed Response (needinfo reporter)

Thanks for capturing the profile — and for an unusually precise description of the mechanism in
comment 0. Your reading is essentially right: on Windows we do stop the audio endpoint rather than
keeping it alive with silence, on both pause and seek.

Two corrections to where we left this, though, and they're both my side of the conversation rather
than yours.

First, the profile in comment 5 doesn't contain the problem. It's a 10-second recording from
Firefox 153 release in which playback starts on the linked test page and a Loom video finishes, but
there's no pause and no seek anywhere in it — so no audio stream is ever torn down, and the one
stream in the recording runs cleanly with no dropouts. The good news is the recording is otherwise
exactly right (media preset, audio callback tracing on), so it should just be a matter of catching
the moment.

Second, and more importantly: the fix I pointed you at in comment 2 is currently enabled on macOS
only. On Windows the pref that turns it on defaults to off, so simply moving to Nightly won't
change what you hear. Sorry for sending you down that path.

Here's what would actually help, in order:

1. On Nightly (155), open about:config and set media.audio.reuse-stream-on-seek to
   true, restart, and tell us whether the dropout on seeking goes away. This is the real
   test, and your answer would directly inform whether we can turn this on for Windows generally —
   so it's genuinely useful data, not just diagnosis for your machine.
2. Please tell us separately whether pausing and seeking behave differently for you. They
   take different code paths and we currently only have a fix for seeking, so knowing whether one
   is worse than the other matters.
3. If you can, re-record a media profile that actually contains a pause and a seek: start
   recording, play for a few seconds, pause, wait ~2 seconds, resume, then seek once, then stop
   the recording. Same steps as before otherwise.
4. Your profile shows 18 add-ons installed, several of which touch YouTube or audio (Video
   DownloadHelper, YouTube High Definition, YouTube To Mp3 Button, an audio-recognition add-on).
   Could you check whether the dropout still happens in Troubleshoot Mode
   (Help → Troubleshoot Mode)? A closely related bug turned out to behave differently there, so
   it's worth ruling out.

On your suggestion of streaming silence during pause: that's a reasonable idea and we've noted it,
but it's a different trade-off from the seek case (holding a Bluetooth device awake through a long
pause costs battery on both ends), so we'll track that part separately rather than lose it in this
bug.

Bugzilla Use Tracking

• Total Bugzilla Queries: 27
• Total Bugs Processed: 8 fully (2055266, 2052692, 2050845, 2055541, 1990361, 2008968, 1977352,
  2011679); ~75 assessed from lightweight search results and the meta's dependency list
• Estimated Download Bandwidth Used: ~0.6 MB Bugzilla; the shared profile was additionally downloaded
  by profiler-cli
• Inaccessible Bugs Due to Permissions: none

Comment 7

[Jim Mathies [:jimm]]

Try testing in Nightly with media.audio.reuse-stream-on-seek=true

Comment 8

[Serhan Apaydın]

I believe this is similar to (or exactly the same) what I'm experiencing with my Sennheiser ACCENTUM Wireless, reported on this comment. In summary, if I repeatedly press right arrow key to fast-forward a video, the headphone completely switches off randomly. It's also reproducible on Firefox 155.0a1, but hooray! I was not able to reproduce it with the media.audio.reuse-stream-on-seek=true setting.

Comment 9

[Alastor Wu [:alwu]]

(In reply to Serhan Apaydın from comment #8)

I believe this is similar to (or exactly the same) what I'm experiencing with my Sennheiser ACCENTUM Wireless, reported on this comment. In summary, if I repeatedly press right arrow key to fast-forward a video, the headphone completely switches off randomly. It's also reproducible on Firefox 155.0a1, but hooray! I was not able to reproduce it with the media.audio.reuse-stream-on-seek=true setting.

Thanks for verifying. Then I will set this bug duplicated to bug 2059525. We will enable media.audio.reuse-stream-on-seek=true by default on all platforms once it's proved not to cause any major regression.