Open Bug 1821102 Opened 2 years ago Updated 4 months 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)

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.

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