Roon on iMac acquires but does not release sleep prevention registrations [Resolved]

Miller_Abel · October 11, 2021, 5:11pm

Roon Core Machine

iMac (Retina 5K, 27-inch, 2019)
3.1 GHz 6-Core Intel Core i5
40 GB 2667 MHz DDR4
Radeon Pro 575X 4 GB
macOS BigSur v11.6 (20G165)

Networking Gear & Setup Details

Hardwired Ethernet to broadband Internet. All issues reproduced using CoreAudio local and Core is running on the same machine. Networking not relevant here.

Connected Audio Devices

Dragonfly Black USB plugged into iMac running Roon Core, fixed volume, audio out connected to O2 Headphone Amplifier.

Number of Tracks in Library

3,500 tracks (I’m just a few days into my Roon trial)

Description of Issue

2021-10-11T07:00:00Z

Once playback has been started at least once (either using a Roon remote app or directly on Core app, doesn’t matter), Roon prevents iMac from sleeping, even when it is idle.

Roon left on overnight after pausing a playlist to RAAT connected CXNv2. This morning, I noticed iMac never slept and Roon was holding 16 sleep prevention registrations.

Here is what pmset reports:

% pmset -g

System-wide power settings:
Currently in use:
 standby              1
 Sleep On Power Button 1
 womp                 1
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 proximitywake        1
 powernap             0
 gpuswitch            2
 networkoversleep     0
 autorestart          0
 standbydelayhigh     86400
 sleep                25 (sleep prevented by Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon, Roon)
 hibernatemode        3
 disksleep            10
 ttyskeepawake        1
 displaysleep         25
 highstandbythreshold 50
 standbydelaylow      86400

Quitting and restarting Roon causes all registrations to be released and no new registrations acquired:

% pmset -g

System-wide power settings:
Currently in use:
 standby              1
 Sleep On Power Button 1
 womp                 1
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 proximitywake        1
 powernap             0
 gpuswitch            2
 networkoversleep     0
 autorestart          0
 standbydelayhigh     86400
 sleep                25
 hibernatemode        3
 disksleep            10
 ttyskeepawake        1
 displaysleep         25
 highstandbythreshold 50
 standbydelaylow      86400

After resuming a paused track, this time just playing to local DAC/headphones, one registration is acquired:

sleep 25 (sleep prevented by Roon, nsurlsessiond, sharingd, coreaudiod)

And one additional registration is acquired each time I resume playback to the local DAC. Here is the result after playing and pausing two additional times (total of starting Play three times since restart of the Roon app on iMac):

sleep 25 (sleep prevented by Roon, Roon, Roon, sharingd, coreaudiod)

Quitting Roon releases all sleep prevention registrations:

sleep 25

Simply restarting Roon adds no new registrations:

sleep 25

EDIT: Here are the detailed assertions and process affiliations:

   pid 80653(Roon): [0x000a6e5100019200] 00:09:35 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a6e2e000191d7] 00:10:10 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a6dc6000191a8] 00:11:54 NoIdleSleepAssertion named: "Music is playing"  
   pid 190(coreaudiod): [0x000a6e5300019210] 00:09:33 PreventUserIdleSystemSleep named: "com.apple.audio.AppleUSBAudioEngine:AudioQuest:AudioQuest DragonFly Black v1.5:AQDFBL0100111456:1.context.preventuseridlesleep"  
	Created for PID: 80655.

PIDs referenced above:

80653 ?? 6:42.86 /Applications/Roon.app/Contents/MacOS/Roon
80655 ?? 0:18.16 /Applications/Roon.app/Contents/RAATServer.app/Contents/MacOS/RAATServer

Hope this is helpful!

DaveN · October 11, 2021, 5:33pm

I suspect this is an issue that affects a limited number of Roon users as exactly the same problem was reported in 2016 (running through to 2019). Thus far there has been no solution.

Miller_Abel · October 11, 2021, 8:53pm

@DaveN thanks for linking to the prior thread. Since I can now reliably reproduce this using Roon app running on a fixed iMac with Ethernet and using a directly connected CoreAudio device, I’m hopeful the problem can be diagnosed.

I’m prepared to work with Roon support to iterate and reduce this further, if they would like. It’s pretty simple now:

Start Roon. Play something. Power assertions created by Roon app and by CoreAudio (on behalf of RAAT Server).

Pause. Notice that power assertion is released by CoreAudio but assertion remains held by Roon app.

Play. Pause. Notice another power assertion is now held by Roon app. There are now two.

(Lather and repeat.)

Additional power assertions held by Roon app whether playing or while paused.

Wait 30 minutes. See that iMac does not sleep. Confirm with pmset -g that assertions are still held and idle sleep is blocked.

Quit Roon app. See that power assertions have now been all released.

Wait 30 more minutes. See that iMac sleeps as configured.

Here is the power assertions log showing results in time for Play. Pause. Play. Pause.

2021-10-11 14:01:00 -0700 : Showing all currently held IOKit power assertions
Assertion status system-wide:
   BackgroundTask                 0
   ApplePushServiceTask           0
   UserIsActive                   1
   PreventUserIdleDisplaySleep    0
   PreventSystemSleep             0
   ExternalMedia                  1
   PreventUserIdleSystemSleep     1
   NetworkClientActive            0
Listed by owning process:
   pid 136(WindowServer): [0x000a62f300098f0d] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:1000058f9 name:AppleHIDKeyboardEve product:Magic Keyboard with eventType:3"  
	Timeout will fire in 1500 secs Action=TimeoutActionRelease
   pid 80653(Roon): [0x000a77870001944c] 00:02:15 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a776f00019449] 00:02:38 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a7621000193d7] 00:08:13 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a75cd000193cc] 00:09:36 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a75a6000193ca] 00:10:15 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a6e5100019200] 00:41:32 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a6e2e000191d7] 00:42:08 NoIdleSleepAssertion named: "Music is playing"  
   pid 80653(Roon): [0x000a6dc6000191a8] 00:43:52 NoIdleSleepAssertion named: "Music is playing"

Time             Action      Age       Type                          PID                 ID                  Name                                              
====             ======      =======   ====                          ===                 ==                  ====                                              
10/11 13:58:21   Created     00:00:00  NoIdleSleepAssertion          80653               0xa776f00019449     Music is playing                                  
10/11 13:58:22   TurnedOn    00:00:00  PreventUserIdleSystemSleep    190(80655)          0xa77710001940c     com.apple.audio.AppleUSBAudioEngine:AudioQuest:AudioQuest DragonFly Black v1.5:AQDFBL0100111456:1.context.preventuseridlesleep
10/11 13:58:25   Created     00:00:00  BackgroundTask                434(1431)           0xa7774000b944a     com.apple.cs.postinstall                          
10/11 13:58:25   System wide status: BackgroundTask: 1  
10/11 13:58:25   Released    00:00:00  BackgroundTask                434(1431)           0xa7774000b944a     com.apple.cs.postinstall                          
10/11 13:58:25   System wide status: BackgroundTask: 0  
10/11 13:58:39   TurnedOff   00:00:16  PreventUserIdleSystemSleep    190(80655)          0xa77710001940c     com.apple.audio.AppleUSBAudioEngine:AudioQuest:AudioQuest DragonFly Black v1.5:AQDFBL0100111456:1.context.preventuseridlesleep
10/11 13:58:43   Created     00:00:00  BackgroundTask                33745               0xa7785000b944b     com.apple.metadata.mds_stores.power               
10/11 13:58:43   System wide status: BackgroundTask: 1  
10/11 13:58:44   Released    00:00:01  BackgroundTask                33745               0xa7785000b944b     com.apple.metadata.mds_stores.power               
10/11 13:58:44   System wide status: BackgroundTask: 0  
10/11 13:58:44   Created     00:00:00  NoIdleSleepAssertion          80653               0xa77870001944c     Music is playing                                  
10/11 13:58:45   TurnedOn    00:00:00  PreventUserIdleSystemSleep    190(80655)          0xa77880001940c     com.apple.audio.AppleUSBAudioEngine:AudioQuest:AudioQuest DragonFly Black v1.5:AQDFBL0100111456:1.context.preventuseridlesleep
10/11 13:59:12   TurnedOff   00:00:26  PreventUserIdleSystemSleep    190(80655)          0xa77880001940c     com.apple.audio.AppleUSBAudioEngine:AudioQuest:AudioQuest DragonFly Black v1.5:AQDFBL0100111456:1.context.preventuseridlesleep
10/11 13:59:14   Created     00:00:00  BackgroundTask                33745               0xa77a5000b944d     com.apple.metadata.mds_stores.power               
10/11 13:59:14   System wide status: BackgroundTask: 1  
10/11 13:59:15   Released    00:00:01  BackgroundTask                33745               0xa77a5000b944d     com.apple.metadata.mds_stores.power               
10/11 13:59:15   System wide status: BackgroundTask: 0  
10/11 13:59:25   Created     00:00:00  BackgroundTask                434(1431)           0xa77b0000b944e     com.apple.cs.postinstall                          
10/11 13:59:25   System wide status: BackgroundTask: 1  
10/11 13:59:25   Released    00:00:00  BackgroundTask                434(1431)           0xa77b0000b944e     com.apple.cs.postinstall                          
10/11 13:59:25   System wide status: BackgroundTask: 0

You will see above the CoreAudio assertion Turned On and Turned Off by CoreAudio (PID 190) on behalf of RAAT server, and as a consequence of exclusive play and pause. But you see only the Creates for Roon app assertions, they are never released.

At this point, I quit the Roon applicaiton:

10/11 14:08:32   ClientDied  00:51:24  NoIdleSleepAssertion          80653               0xa6dc6000191a8     Music is playing                                  
10/11 14:08:32   ClientDied  00:49:40  NoIdleSleepAssertion          80653               0xa6e2e000191d7     Music is playing                                  
10/11 14:08:32   ClientDied  00:49:05  NoIdleSleepAssertion          80653               0xa6e5100019200     Music is playing                                  
10/11 14:08:32   ClientDied  00:17:48  NoIdleSleepAssertion          80653               0xa75a6000193ca     Music is playing                                  
10/11 14:08:32   ClientDied  00:17:08  NoIdleSleepAssertion          80653               0xa75cd000193cc     Music is playing                                  
10/11 14:08:32   ClientDied  00:15:45  NoIdleSleepAssertion          80653               0xa7621000193d7     Music is playing                                  
10/11 14:08:32   ClientDied  00:10:10  NoIdleSleepAssertion          80653               0xa776f00019449     Music is playing                                  
10/11 14:08:32   System wide status: PreventUserIdleSystemSleep: 0  
10/11 14:08:32   Released    04:18:23  PreventUserIdleDisplaySleep   190(80655)          0xa4c6100058830     com.apple.audio.context689.preventuseridledisplaysleep
10/11 14:08:32   Released    04:18:23  PreventUserIdleSystemSleep    190(80655)          0xa4c610001882f     com.apple.audio.context689.preventuseridlesleep   
10/11 14:08:32   Released    04:18:23  PreventUserIdleDisplaySleep   190(80655)          0xa4c6100058834     com.apple.audio.context690.preventuseridledisplaysleep
10/11 14:08:32   Released    04:18:23  PreventUserIdleSystemSleep    190(80655)          0xa4c6100018833     com.apple.audio.context690.preventuseridlesleep   
10/11 14:08:32   Released    00:12:42  PreventUserIdleDisplaySleep   190(80655)          0xa76d800059415     com.apple.audio.AppleUSBAudioEngine:AudioQuest:AudioQuest DragonFly Black v1.5:AQDFBL0100111456:1.context.preventuseridledisplaysleep
10/11 14:08:32   Released    00:09:46  PreventUserIdleSystemSleep    190(80655)          0xa77880001940c     com.apple.audio.AppleUSBAudioEngine:AudioQuest:AudioQuest DragonFly Black v1.5:AQDFBL0100111456:1.context.preventuseridlesleep

The system cleans up the stale assertions when the app exits, but “Client Died” means the app never released them on its own.

There are other assertions here, I’ve left them to inform the context, but they are not likely to be relevant to the problem which appears to be with the Roon app not releasing power assertions when paused.

This has the hallmarks of a reference count error. The program context that created the power assertion may not be properly finalizing and so it does not actively release the power assertions, even though it has code to do that. Or else the finalizer doesn’t have the required code to release the power assertions.

There appears to be no problem changing the sleep timeout to a shorter value to make full end-to-end testing simpler. But unless the power assertions are released, the Mac is not going to sleep, so that is a good enough proxy until a tentative fix is found when it can then be verified by waiting to see that the system sleeps properly.

wizardofoz · October 12, 2021, 1:29pm

If you try using the roon server app and close the roon remote does this still happen?

Miller_Abel · October 13, 2021, 1:29am

Yes, @wizardofoz , the repro is all using the app running on same machine as in-built core. The app is on the iMac and core is part of the app.

To clarify, the RAAT server is launched by and is managed by the Mac Roon app. It is not a separate install on this system.

wizardofoz · October 13, 2021, 3:36am

What I am saying is try using the Roon Server app as your Core and then see if there is still an issue with sleep.

BUT why run a core with sleep enabled is just not the expected way to run a server. If power is an issue shut it down at night and start it up again in the morning - Macs can do this in the power/batter schedule settings. Use the automatic login and set the server to run at login.

Miller_Abel · October 13, 2021, 4:10am

Hmmm…No, I use the Mac as it was intended, and with properly functioning software, it will sleep when idle. Wake on Lan enables remote software to wake it when needed. I’m not going to configure my home Mac as a server. If I decide to stay with Roon, I may build a NUC to unburden my Mac, but this really should not be necessary.

If the Roon Server installed separately and configured to sleep, as you’re suggesting, what would the advantage be? The app already launches RAAT Server when it’s running, and shuts it down when the app exits. I have no reason to close the app, unless it misbehaves.

Are there other differences or advantages between Server and app I may not be appreciating?

I do appreciate the suggestions, thank you!

wizardofoz · October 13, 2021, 4:15am

Whether you use Roon or Roon Server as your Core, Roon is a server and as such should be treated as one for the environment its running in/on.

Miller_Abel · October 13, 2021, 5:03am

This is just a software bug in the app and it should be fixed. It’s not a critical or crash bug, but it’s not trivial either.

If you study the logs I shared above in this thread, you’ll see that RAAT Server is working correctly. It defers to CoreAudio daemon for sleep prevention only while music is playing.

It is the app that fails to release additional power assertions that the app itself acquires. The only way to cause the sleep assertions to be released is to quit the app. So separately installing the server would not make a difference.

Miller_Abel · November 1, 2021, 12:32am

@support, any update on this bug? Mac will not sleep after playback initiated by any controller. Rune Core, running within the Mac Roon App, is collecting and holding sleep prevention assertions, one for each time play is initiated by any controller. Wake to find work computer has drained its battery because it never slept.

noris · November 3, 2021, 5:19pm

Hello @Miller_Abel ,

Thank you for the report here! We have an existing development ticket regarding this issue, and we have added your report to this ticket.

I can see that the ticket regarding this behavior is still in our development queue, which means developers are planning to address it, but we don’t have a timeframe for when that’s going to happen.

Once the ticket has been scheduled and work begins, I’ll have a better sense of timing here. Thanks in advance for your patience!

Miller_Abel · November 3, 2021, 11:24pm

Thank you @noris, I appreciate the followup!

DaveN · November 4, 2021, 1:51am

Would that be the same one that was opened in 2016?

Doc_Coop · November 8, 2021, 5:05pm

Hi,

I have the same problem and can confirm the error.

I run a Roon server/core on a Mac mini. Apparently the server doesn’t notice when music playback has been stopped and therefore permanently prevents the Mac (=the server) from going into standby/sleep mode.

The command “pmset -g assertions” in the server’s terminal gives the following output:

"pid 437(RoonAppliance): [0x00002a3c00018564] 00:48:03 NoIdleSleepAssertion named: “Music is playing”.

This behavior is completely analogous to the bug reported here since 2016 and I would be more than happy if it could be fixed soon, because my Mac server consumes significantly more power in operation than in standby (15W vs. 1.5 W!!!).

Otherwise, Roon is a wonderful piece of software.

Many greetings
Thomas

Doc_Coop · November 8, 2021, 6:57pm

As an addition to my previous post, if anyone is interested:

As a workaround, I wrote a simple script that restarts the Roon server software on the Mac server every night at 1:00 am (at this time no one at our house is playing music anymore). This resets the server and the Mac then goes into sleep mode.

This is not the most elegant and energy saving method, but at least a workaround.

I really hope that someone at Roon will take care of this bug as soon as possible and fix it - thank you.

Regards,
Thomas

DaveN · November 8, 2021, 7:24pm

I run an AppleScript in the background that does a similar thing, but in my case it’s to make sure that Roon Server doesn’t eat its way through too much RAM. Out of interest, how are you running your script at a particular time?

DaveN · November 8, 2021, 7:56pm

Give them a chance, it’s only been five years

Doc_Coop · November 8, 2021, 8:49pm

Hehe, that’s exactly what I was thinking…so it’s important for me to stress that your problem/observation is not an isolated case and that basically all users who have a Mac and are interested in sleep mode/energy saving have this problem, because I’ve read it in several other places here on the forum as well.

…the next question is, why Roon can’t send a WOL/magic packet to wake up the server, like e.g. the Logictech media server can do it since more than 15 years…

I followed this guide (hope I’m allowed to post the link here) and replaced the fixed time interval of 3600s with a calendar entry:

https://www.reddit.com/r/mac/comments/afw5sn/scheduled_app_restart/

Calendar entry instead of time interval:

<key>StartCalendarInterval</key>

<dict>

    <key>Minute</key>

    <integer>00</integer>

    <key>Hour</key>

    <integer>01</integer>

</dict>

So the server is always shut down once briefly at 01:00 AM and restarted again.

…Feels good that there are already two of us now…

DaveN · November 8, 2021, 9:10pm

I should probably go the same route - i.e. a Launch Agent rather than a continually running AppleScript - but it runs a few other tasks that I can’t be bothered to rewrite, so I’ll leave it for now. Thanks for the link though

Doc_Coop · November 8, 2021, 9:13pm

You’re welcome…