Mac Studio sleep issue? coreaudioD spamming my log with Released PreventUserIdleSystemSleep...

[JeffPerrin]

Trying to track down potential sleep behavior issue on my new Mac Studio M4 running MacOS 15.3 and noticed every few minutes, 24/7, the pmset log gets spammed by coreaudiod with approx 30 lines of the following message:

2025-04-29 09:20:22 -0400 Assertions PID 170(coreaudiod) Released PreventUserIdleSystemSleep "com.apple.audio.context433.preventuseridlesleep" 00:01:00 id:0x0x1000083fd [System: PrevIdle DeclUser kDisp]

Any ideas what is going on here?

 

[Fishrrman]

What do you have plugged into the Studio?

 

[JeffPerrin]

Right now, just keyboard and display.

 

[JeffPerrin]

Display does have speakers (HDMI audio)

 

[Fishrrman]

"Display does have speakers (HDMI audio)"

Do you currently have the speakers set for audio output?
(as set in the "sound" preference pane)

If yes, what happens if you disable them, temporarily?
Do the log entries end?

 

[JeffPerrin]

There aren't typically set up as default. Other than selecting a different audio output, how would I disable them? Only thing I can find is removing Apple's HDMI audio kext, but that seems a bit drastic...

 

[nmt1900]

I had coreaudioD preventing sleep as well, but I was able to find out that coreaudioD was spawned by Safari - only when one specific website was open (website with only pictures and no media contaaining video or audio). I started to use that website with other browser and problem went away.

 

[JeffPerrin]

I had coreaudioD preventing sleep as well, but I was able to find out that coreaudioD was spawned by Safari - only when one specific website was open (website with only pictures and no media contaaining video or audio). I started to use that website with other browser and problem went away.

Interesting. I'll keep an eye out for that one.

 

[Fishrrman]

nmt wrote in #7 above:
"I had coreaudioD preventing sleep as well, but I was able to find out that coreaudioD was spawned by Safari - only when one specific website was open"

Could you tell us HOW you were able to "find out"?
What method did you use?
Trial and error, or...?

 

[nmt1900]

Finding out Safari being behind it was simple - pmset -g assertions indicates PID of the process which is spawning coreaudiod (see example below - PID 1825 was "Safari graphics and media") - finding out the webpage was by "trial and error".

[~]$ pmset -g assertions
2025-05-01 20:10:22 +0300
Assertion status system-wide:
BackgroundTask 0
ApplePushServiceTask 0
UserIsActive 1
PreventUserIdleDisplaySleep 0
PreventSystemSleep 0
ExternalMedia 0
PreventUserIdleSystemSleep 1
NetworkClientActive 0
Listed by owning process:
pid 108(powerd): [0x000e9eef0001a32e] 08:50:02 PreventUserIdleSystemSleep named: "Powerd - Prevent sleep while display is on"
pid 178(coreaudiod): [0x000f1b150001a70a] 00:00:21 PreventUserIdleSystemSleep named: "com.apple.audio.BuiltInSpeakerDevice.context.preventuseridlesleep"
Created for PID: 1825.
Resources: audio-out BuiltInSpeakerDevice
pid 165(WindowServer): [0x000e9eef0009a330] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:100000937 service:AppleHIDKeyboardEventDriverV2 product:Apple Internal Keyboard / Trackpad eventType:3"
Timeout will fire in 1800 secs Action=TimeoutActionRelease