Bug: eqMac activates PreventUserIdleDisplaySleep assertion which prevents display sleep or screensaver

[doctorkb]

Disclaimer:
Please go through existing issues to avoid creating duplicates. If you found a similar issue please post a comment there. If you are uncertain your issue is related to others then create the issue. Obvious ignorance of this rule might get you blocked from posting new issues. Please tick the box below to show that you have followed the guideline.

• I have checked for a similar issue and sure it hasn't been reported before.

Describe the bug
When eqMac is enabled, the PreventUserIdleDisplaySleep assertion is raised, regardless of any output. This prevents a screensaver from activating and consequently having the screen lock and sleep.

   pid 2244(coreaudiod): [0x0015161d00058e2c] 00:00:02 PreventUserIdleDisplaySleep named: "com.apple.audio.AppleGFXHDAEngineOutputDP:f803:2:{F005-069E-00000000}.context.preventuseridledisplaysleep"  
	Created for PID: 37780. 
	Resources: audio-out AppleGFXHDAEngineOutputDP:f803:2:{F005-069E-00000000} 

Steps to Reproduce
Steps to reproduce the behaviour (feel free to change the placeholder as you need):

1. Enable eqMac
2. run "pmset -g assertions" - you'll see that the eqMac PID has caused the assertion to be created via coreaudiod
3. wait however long you want - the display won't sleep

Expected behaviour
eqMac should not raise this assertion unless there is audio output occurring.

Setup information:

• Audio device used for playback: HDMI to optical converter
• Audio transmission interface: HDMI
• macOS Version: 14.2.1 (23C71)
• eqMac Version 1.8.5 (has existed since the Sep 2023 release)
• eqMac UI Version 5.0.7 (Remote)
• eqMac Driver Version 2.5.2

[ragauskl]

Duplicate of #645, find solution in there, if it does not work use that issue to follow up

[doctorkb]

This isn't the same issue, though they're similar.

I've tried changing that timeout, but it's a hack and only sort of works. An alert tone is enough to renew that timeout, even though it shouldn't.

eqMac shouldn't be raising that assertion unless it is by proxy from another application, and it can lower it when the other application lowers it. Typically, that would only happen with a live video stream.

Bottom line, this isn't "completed" nor is it appropriate to try to merge into that other issue.

[ragauskl]

I've talked with the dev regarding this issue and depending on your expectations there are multiple solutions.

First I need to clear some things up. How it works currently:

1. PreventUserIdleDisplaySleep is not explicitly handled by eqMac, but is/may be a side effect of eqMac routing audio through the selected output device (similarly as you've mentioned in step 2 of how to reproduce the issue).
2. Currently all audio is treated equally and will reset the 'Pause Audio Processing' timer.
3. As eqMac is processing the audio, even if there's no audio, it's routing data through the selected output device in turn likely causing PreventUserIdleDisplaySleep in this case as side effect.
4. When 'Pause Audio Processing' time has elapsed since last 'sound' of any type, eqMac will stop processing audio and sending data to the output device.
5. When audio is coming out from eqMac it cannot be separated/indentified by the system as audio from an app or a system sound

What can be done:

1. System sounds do not reset the 'Pause Audio Processing' - Let's say you set the Processing timer to 3s, you play a video and stop it, the 3s timer starts countdown and a system sound occurs. Dev can change it so that the system sound does not reset this timer. Empty audio will continue being piped to the output device until Processing timer is done. macOS will release PreventUserIdleDisplaySleep as eqMac stops sending data to output device (+ any time macOS needs to detect it or if it has any internal timer - I'm not sure how instant that is), then the X amount of time set by user power saving settings will be still required for the device to go to sleep. So if you set to go to sleep after 10min of inactivity, in the end it will still be total time of eqMac Procesing timer + macOS time to release PreventUserIdleDisplaySleep + 10min for sleep.
   • In the end, it will go to sleep sooner but may not be as soon as you'd like.
2. Route system sounds directly to the output device/bypass eqMac - As mentioned in No5 above, macOS cannot identify system sounds once they are routed through eqMac and skip using 'PreventUserIdleDisplaySleep' if the sound is produced by the system notification, alert or other. As eqMac can identify this, if a sound is made by system, a change can be added so that that sound is directly routed to the output device meaning macOS can identify it .
   • While this will not reduce the time required for device to sleep after audio stops being produced by let's say a video, as the eqMac Processing timer will still be triggered, it will prevent Processing timer from starting again if system sound occurs when the Processing timer is inactive and the 10min timer set for sleep is counting down.
   • A downside to this is also that as system sounds will not be routed through eqMac, users won't be able to control the volume level or other settings for them in eqMac.

Let me know if any of these solutions are what you're looking for or provide further explanation of what you're expecting to happen.

As the original issue did not mentioned 'ignoring system sounds' I still believe I've closed/linked it correctly with the other issue as based on how eqMac was designed to work the underlying issue and solution is the same in both.

Due to your following mention of the fact that the system sounds should not further delay the sleep, changes this from a bug to a feature/user experience upgrade request as treating system sound as any other audio related to sleep prevention is the current intended behavior as alternatives also have their downsides. I can see how it's not the ideal user experience but it's still a behavior change/feature request rather than a bug. If you agree with this I can change the title to 'Feature: System sounds should not further delay sleep' or similar based on your expected solution to this and reopen it.

If you however disagree with the above paragraph, a further explanation of how you understand this issue and why you disagree will be useful.