Open Bug 1821102 Opened 3 years ago Updated 13 days ago

Firefox keeps coreaudiod active, which prevents sleep on MacOS

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 112
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: alanruttenberg, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

Run Firefox for a while. If laptop is not plugged in, it periodically runs out of battery even with the lid closed and being charged a reasonable amount, and reboots when next opened up.
Use "pmset -g" to see if anything is blocking sleep.
I sometimes see a line " sleep 1 (sleep prevented by coreaudiod)".
Quit Firefox, and the entry goes away - nothing is listed as preventing sleep.
Quitting other applications does not affect the entry.
If I wait for a while and check again the pmset coreaudio state does not change.
I am not sure which sites cause this but I suspect outlook.office.com, after it has played a sound, typically when an email arrives or a meeting is about to start.

Actual results:

Laptop reboots because battery has run out (eventually).
The only way to prevent this is by running, each time the machine is to be put to sleep, "pmset -g" and if there's a coreaudiod line, quitting Firefox.
I am running MacOS 10.15.7 on an Intel Macbook Pro.

Expected results:

Firefox should not leave coreaudio active, if that will prevent laptop sleep.

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

Component: Untriaged → Widget: Cocoa
Product: Firefox → Core

Do you have any extensions in your profile, such as "Worldwide Radio" or similar? Does this reproduce in safe mode and/or a new profile?

Severity: -- → S3
Flags: needinfo?(alanruttenberg)
Priority: -- → P3

If not, this might be a duplicate of bug 1734627 and bug 1735412.

Alastor, thoughts here? Might be related to

Bug 1771179 - Pause cubeb streams when an AudioContext has been silent for some time, keeping currentTime ticking
Bug 1809313 - Only request video wakelock for audible video

For one report that showed up on slack, disabling wakelock through prefs appears to have addressed this.

Component: Widget: Cocoa → Audio/Video: Playback
Flags: needinfo?(alwu)

Can you use pmset -g assertions to see if there is an audio-playing wakelock requested by Firefox when core-audio wakelock appears? Starting from Fx102, we won't create audio backend for muted audio. If core-audio exists, then it means there is audible audio playing, or a web audio is running (no matter it's silent or not, currently we haven't stopped running the audio back-end for web audio, see bug 1771179)

audio-playing wacklock can be used to distinguish these two situations. Thank you.

Flags: needinfo?(alwu)

I'm experiencing the same issue, and there's no wake lock according to pmset -g assertions.

Symptoms for me: 0% coreaudiod after a fresh Firefox restart, but as soon as any tab plays audio a single time (easiest example: move a chess piece on https://lichess.org/analysis), it never drops below 10%, even long after the tab is done playing any sound (i.e. the "playing sound" indicator goes away in the tab bar).

I don't have any audio-related extensions running.

Just tested again using a clean install and clean profile: Same symptoms.

This is using Firefox 123.0.1, macOS 14.4, on an M1 MacBook Pro.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jimm, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(alanruttenberg) → needinfo?(jmathies)

Did some further testing: The high CPU usage goes away once the last tab having ever played audio since the last Firefox restart is closed.

This is easily reproducible on a fresh profile by opening any soundcloud link (that opens a player in the paused state), e.g. https://soundcloud.com/trending-music-de/sets/latin, and checking the "Energy" tab in activity monitor. Firefox is marked as "Preventing sleep: yes", closing the soundcloud tab changes it to no.

Flags: needinfo?(jmathies)

I have the same issue (and have for a long time, but currently on 134.0).

In addition to draining the laptop battery, this also:

  • mutes some wireless headphones (bose qc3) when using with e.g. a phone, because macos connects and somehow mutes it. Closing firefox resolves this mute.
  • seem to drain the battery of airpods, which are kept on due to coreaudiod. Closing firefox resolves the draining.

This is also intermittently, so I can leave Firefox open most of the time, which I do, and so I end up encountering this bug regularly.

Personally, I would rate this above P3, as it causes a degraded performance not only in Firefox. Not fun waking up to a drained laptop when going on a trip, or having to open up the laptop from my backpack to close Firefox just to use headphones on my phone.

I feel like there are actually two issues here:

  • Web Audio contexts created but not producing any sound. I don't know the details of the Web Audio API, but there seems to be a suspend() method that sites are supposed to use, and many apparently don't.
    In my experience, these sites end up creating a wake lock on macOS, which is clearly visible in Activity Monitor in the "energy" tab: Firefox is listed as "preventing sleep" as long as this is the case. One example is Soundcloud as linked above; another is available here: https://editor.43z.one/sqare/i

  • Anything, Web Audio or not, that has ever played any sound, seems to permanently cause high coreaudiod CPU usage on macOS. This includes Web Audio sources, but is not limited to them, and persists beyond the Web Audio source being suspended or destroyed (as observable by the wake lock going away in Activity Monitor); it also happens for videos etc.

The "empty Web Audio context" bug seems to exist across platforms (see also this detailed blog post with reproducing examples: https://h.43z.one/blog/2025-02-12/), but whatever is happening on macOS seems to go beyond that. Fixing the Web Audio bug seems necessary, but not sufficient to solve whatever is happening with coreaudiod.

I am having the same issue. Simple steps to reproduce:

  1. Run sudo pmset -g:
 sleep                1 (sleep prevented by bluetoothd, powerd)
  1. Visit https://www.keybr.com/ and enable sound via settings, and type one letter
  2. Run sudo pmset -g && sudo pmset -g assertions
 sleep                1 (sleep prevented by sharingd, powerd, firefox, useractivityd, coreaudiod, bluetoothd)

   pid 5158(firefox): [0x0003328d00019eaf] 00:00:01 NoIdleSleepAssertion named: "audio-playing"
   pid 402(coreaudiod): [0x0003326300018ee0] 00:00:49 PreventUserIdleSystemSleep named: "com.apple.audio.25C90027-0000-0000-1221-0104B53C2178.context.preventuseridlesleep"
	Created for PID: 5158.
	Resources: audio-out 25C90027-0000-0000-1221-0104B53C2178

It's seemingly easy to blame the web developers for improper use of web audio contexts, but I think the fact that other browsers have solved the issue (ie: Chrome) indicates that Firefox can do the same. This is a pretty annoying bug, because basically if any tab ever plays audio (even once), then my Mac will no longer sleep. I'd prefer not to have to close tabs or close Firefox to be able to sleep my computer.

Blocks: media-sleep

Still present on Firefox 153.0.3 / macOS 26.6.1 (25G76) / Apple M5. This bug lists "112+"; adding a trigger and the HTMLMediaElement-vs-WebAudio discriminator asked for in comment 5.

Impact

Overnight 2026-08-10 → 08-11 the machine never slept: 0 sleeps and 0 DarkWakes between 00:00–08:00, against 33 and 36 the two nights before. On battery from ~20:30 at 80%, down to 1% by 08:20 — ~6.9%/h with the display off. It ended only because macOS forced a 'Low Power Sleep' at 1%, which is the one thing that overrides the assertion:

2026-08-11 08:20:49  Sleep  Entering Sleep state due to 'Low Power Sleep' ... (Charge:1%)
2026-08-11 08:20:49  PID 609(coreaudiod) TurnedOff PreventUserIdleSystemSleep
      "com.apple.audio.BuiltInSpeakerDevice.context.preventuseridlesleep" 12:32:40
                      Created for PID: <firefox parent>
                      Resources: audio-out BuiltInSpeakerDevice

Held continuously 12h32m — powerd re-summarised it every 15 min for 64 consecutive ticks.

Trigger: Bluetooth output device teardown

Onset correlates to the second with a BT output device going away. Twice on the same day:

12:40:49  BT <98-52-...> audio context TurnedOff
12:40:50  Firefox takes BuiltInSpeakerDevice     -> held 3h+

19:48:08  BT <CC-22-...> audio context TurnedOff  (WebRTC call ended 19:47:23)
19:48:09  Firefox takes BuiltInSpeakerDevice     -> held 12h32m

When the default output device disappears, the stream is reopened on the new default and never closed.

Discriminator asked for in comment 5

Firefox holds no assertion of its own during the entire 12.5 h window. Across ~4 days of pmset -g log, "audio-playing" appears exactly once (Aug 5, held 00:04:57, released cleanly) and "video-playing"/"screen" appear on other days, always released.

So the bug 1373888 wake-lock work looks correct — Firefox knows nothing is playing. The assertion is taken one layer below by the CoreAudio HAL, because the cubeb/AudioUnit output stream is still open and running, and Firefox's accounting never sees it. Matches comment 6's "zero wakelock despite coreaudiod elevated".

Restarting coreaudiod does not clear it

sudo killall coreaudiod → re-taken in 47 ms, so this isn't stale coreaudiod state:

09:58:52.929  HALB_PowerAssertion::Release: ... on behalf of <firefox pid> for 1.142362 seconds
09:58:52.939  HALS_IOContext_Legacy_Impl::IOWorkLoopInit: 264 BuiltInSpeakerDevice: starting
09:58:52.941  HALB_PowerAssertion::Take:    ... on behalf of <firefox pid>

Only quitting Firefox releases it. Sampled age is monotonic (1:29 → 1:33 → 1:37), so it's pinned, not churning.

Frequency

Actively-held hours per day, from powerd's 15-min Summary ticks: 22.2, 13.2, 3.5, 1.5, 3.5, 0.2, 11.2, 8.8 (Aug 4–11). Same tabs open throughout, so it tracks headset use, not page content. Aug 9 is the control — 0.2 h held, machine slept 33 times that night.

Caveat

I can't rule out a page holding a running AudioContext: 3 of 9 content processes have a live MediaTrackGrph thread, and those tabs are web messengers (WhatsApp Web, Yandex Messenger, MAX). That's the suspended-Web-Audio half of comment 12 rather than a competing explanation — Chrome releases the device within seconds in the same situation (bug 1165677). I couldn't map content process → tab externally: networking is in the parent, XUL is stripped, and content processes hold no origin-identifying files.

Steps to reproduce

Observed twice from logs, not yet reproduced deliberately — I can attempt an on-demand repro if that helps.

  1. Open a page with a Web Audio context (a web messenger will do).
  2. Play audio through Bluetooth headphones (a WebRTC call reproduces both observed instances).
  3. Disconnect the headset / end the call so the BT output device tears down.
  4. pmset -g assertions | grep -A3 BuiltInSpeakerDevice — expected: nothing once audio stops. Actual: coreaudiod holds PreventUserIdleSystemSleep on behalf of the Firefox parent PID indefinitely, and the machine never idle-sleeps.

Also useful: log show --last 5m --predicate 'process == "coreaudiod"' | grep PowerAssertion and pmset -g log | grep 'coreaudiod) Summary'.

Given the trigger, and that Firefox's own wake locks are clean, this may belong in Core :: Audio/Video: cubeb rather than Playback — possibly adjacent to bug 1757262 ("Do not reinitialize audio stream if its device isn't changed").

You need to log in before you can comment on or make changes to this bug.