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.

[doctorkb]

I think the issue is with your assertion 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."

That's not how it works when other software is sending audio to the system. Audio-only tools like Spotify don't raise that assertion when they're talking directly to the system audio. This assertion is only raised when there's an apparent video component that you wouldn't want to be interrupted (like if watching Netflix meant you had to move the mouse to prevent the screensaver from kicking in).

I've also found a few buggy applications that fail to lower it correctly (the Google Voice application is one example -- it raises it for a phone call, but fails to lower it until you quit the application).

This issue is relatively new in eqMac. I don't know the specific version number, but at some time prior to the current one, it only raised the assertion if the audio-generating application raised it. And it (usually) lowered it correctly as well.

[ragauskl]

Spotify is not a good example in this case as it outputs audio without need of intercepting anything, where's eqMac is more complicated because it has to intercept the audio, process it and then output it again. So we should be comparing eqMac with alternative solutions like other equalizers for macOS. Now intercepting can be done in couple of ways, some are much more complex and require more in-depth and proprietary knowledge of how macOS works as it requires using undocumented private APIs and more (so teams had or still have people that previously worked at Apple and are able to do more). This issue and this setting is related to how eqMac handles the audio, however as it's no longer an open-source project I can't get into the details of why and how. Just can clarify that I've phrased that wrong, it's not sending empty data on purpose, that is also just a side effect of current implementation that can't be disabled as long as eqMac is active.

Previously eqMac did not have a 'Pause Audio Processing' option (which currently can be achieved by setting the settings to 'Instantly') so you may be referring to that time when option to 'Instantly' pause the audio processing was the default. However for many people this caused issue where first half of the system sound would not get played and only the end. This is because eqMac needs time to start processing and outputting the audio again. Therefore the setting was introduced so people for whom it's a big issue can set eqMac to 'Never' stop processing audio, which in turn solves the issue but causes sleep prevent. Now sleep prevent for majority of users does not cause any issue, but for some it does, so the slider allows to set some 'balance' between the 2 issues.

Dev said the best thing he can do atm in one of upcoming updates is just by default not route any system sounds through eqMac, which may likely mean that their volume also won't be controllable (but maybe he'll find separate solution for that) through eqMac but the need for that should be more niche/rare than the issue with current system sounds both in having them cut-off and having to use setting to 'Never' but then preventing sleep.

[doctorkb]

Spotify isn't a counter example to eqmac. I wasn't using it as such. I was using it as an example of an audio source that, when sending to the normal audio processing, doesn't raise this assertion. Previously, eqMac behaved as a proxy -- if the audio source raised it, it would raise it, but if it didn't, it wouldn't.

THAT is correct behaviour. I shouldn't have to deal with that hack of pausing processing just to have my screen power down correctly.

I'm also unclear on how you're not even named as a contributor, have said you don't have access to the code, but you're going around closing other people's issues.

[ragauskl]

Regarding Spotify I do understand that and that's why I said 'in this case'. What I meant is that we need to look at how and when PreventUserIdleDisplaySleep is triggered by them and not Spotify as equalizers require more usage of various macOS APIs and other things making it more complex and sometimes possibilities are limited by what macOS provides the developers with.

I never said I 'don't have access to the code', what I said is 'as it's no longer an open-source project I can't get into the details of why and how'. What I was saying is 'The owner/developer of this project has explained this issue and reason behind some decisions in detail on my request so that I can understand your case better, but as he chose to stop maintenance of the open source repository and eqMac has now for a long time been a closed source project, he asked not to disclose any details as this is now proprietary information'.

I'm not arguing with you whether it is the correct behavior or not. I do understand you side and that such behavior would be a better user experience, so I went to the dev and provided you with a solution he can offer in upcoming updates. You can argue all you want whether it's a good or bad solution but a lot of factors go into making a decision to add one solution over other, just one of many examples - if there are higher priority issues. That is also completely up to the developer. If you don't like the solutions, like with any other software, you are welcome to use an alternative or not use anything at all.

As mentioned you can continue using previous behavior if you set the 'Pause Audio Processing' to 'Instantly'. This is how eqMac used to work, but for people experiencing issues with system sounds the option was added. If you never had this issue or it doesn't bother your you can use the 'Instantly' setting. Alternatively you'll need to wait for an update.

---

To clarify my position in this, me and Roman(the owner/developer of eqMac) are equal co-owners of Bitgapp. He is fully dedicated to working on eqMac so he knows all the technical ins and outs of eqMac and makes all eqMac decisions. Likewise I fully work on my own project and am fully responsible for my own work. So you don't see me as contributor because I never wrote code for eqMac nor will. Vice versa with Roman and my project.

While I have not worked on eqMac directly I have been by the side of Roman practically since beginning of eqMac and I'm aware of how it changed over time on a 'overview' level. For a while now he had hard time dealing with customer support (what you don't see is hundreds and thousands of support requests through chat system in eqMac) and finding decent amount of time to get actual work done on eqMac, so lately I decided to help him and asked him about all existing issues, if I encounter anything new I also check all information with him and when necessary ask for more detailed explanation. This way he can get more uninterrupted time working as he doesn't have to deal with constant duplicate queries and I can keep him updated on what still needs to be worked on and offer quicker help to non-paying users and those using community support like Github or Discord who otherwise would likely not get reply in months or at all as top priority for Roman are paying users as should be.

I have no bad intentions and am here to genuinely help users, I may not always be right but when I'm not I ask for feedback and check where required with the dev. I've explained this nicely out of patience which I have more than a lot of people, so now you can either continue with your attitude or you can try explaining how exactly this is different from the other issue if you want it reopned as I still see this as just a part of same overall issue 'eqMac preventing sleep' and solution to both issues will be the same.

[doctorkb]

As mentioned you can continue using previous behavior if you set the 'Pause Audio Processing' to 'Instantly'. This is how eqMac used to work, but for people experiencing issues with system sounds the option was added. If you never had this issue or it doesn't bother your you can use the 'Instantly' setting. Alternatively you'll need to wait for an update.

Except that leads to cutting-in issues which is even less desirable.

So you don't see me as contributor because I never wrote code for eqMac nor will.

I understood that in github, only contributors (a permissions level) could close issues. Not that you actually contributed (or not).

I have no bad intentions

Maybe don't close issues until you've actually talked them through, then?

continue with your attitude

That this is buggy and you're being a jerk? Yeah, that's definitely a problem with my attitude. 🙄

'eqMac preventing sleep'

Preventing sleep is different from preventing display sleep. To combine those issues is going to lead to other issues. If the solution is going to be the same, then this isn't worth paying for... tempted as I was to do so once this last kink was ironed out.

[nodeful]

@doctorkb Same issue as #645
Even though the testing hypothesis is different the underlying issue is the same and the solution will be the same for both. I will try to patch this up in the next update.
@ragauskl is the co-founder of the project so she has all the right to manage issues for eqMac