koobas.hobune.stream
How to stop Unity & MonoDevelop preventing my Mac from going to sleep ?
Hi, (I'm french, please excuse any mistake).
have a problem on Mac OS X 11.11.6 and Unity 5.40f3 personal*. EDIT: seems to still be the case in 2017.x
When Unity (and MonoDevelop) are running - and doing nothing - they prevent my Mac from going to sleep. I did not find any setting about that. This is anoying : I have to quit these applications before leaving home to work or going to sleep. I would like to let them running (as for any other app) but electricity is not free and I care about... the planet ?
This is my first ever question on this forum, hope I asked it in the right place. I searched for a similar question but I did not find any.
Thank You. Cédric.
For those whom would like to check this issue by themselves, here is a screenshot of what is happening on the $$anonymous$$ac. The screenshot is in french, but I put in english explanations. Thank you for your help. 
Note : this is still the case in Unity 5.4.3f1
Can anyone at Unity's tell something about it ?
have the same issue - seems to be related to audio session running, based on the output of
pmset -g assertions
I get this additional line when Unity is running:
pid 204(coreaudiod): [0x0000049e00018177] 00:00:12 PreventUserIdleSystemSleep named: "com.apple.audio.AppleHDAEngineOutput:1B,0,1,1:0.context.preventuseridlesleep"
Created for PID: 753.
this is especially annoying if you're on a macbook and the mac won't sleep, draining the battery to zero! this has happened to me a couple of times! (sorry this is not an answer, i can't seem to view or add a comment)
I can confirm that this is still the case in Unity 2017.3 !!!
Please is there any way to turn this off? Because thats the reason why you always have to close unity ins$$anonymous$$d of leaving it open - what is the problem - this is the only program preventing a sleep on mac os....
Im not a MAC user, thank the heavens, but Im quite sure you can simply modify the power settings manually using something like 'pmset' to manually set/reset programs that are registered to prevent sleep.
As it appears Unity's hook on Audio Device is preventing sleep, try clicking "Disable Unity Audio" in Audio Prefs.
https://www.dssw.co.uk/reference/pmset.html
Hmm possible, but I have no idea how to remove unity from this list :)
Since its related to the audio manager of unity which prevents it from going to sleep I wonder how difficult it would be for them to remove this "hook" though.
Erm nope, looks pretty simple to me.
https://www.dssw.co.uk/reference/pmset.html
I believe you need to check 'assertions'. In windows we can directly modify what is registered in these fields and make the OS ignore them etc etc. P$$anonymous$$SET looks pretty extensive but simple. Its just Command Line!
−g assertions displays a summary of power assertions. Assertions may prevent system sleep or display sleep. Available 10.6 and later. −g assertionslog shows a log of assertion creations and releases. Available 10.6 and later.
But yup, Im not a $$anonymous$$AC user so maybe its not very simple and I'm just making grand assumptions, but if its anywhere, its P$$anonymous$$SET based on my grand experience of 10 $$anonymous$$utes reading ;)
Checking the assertions is one thing :) But removing it from there - is a complete different story ;)
Sorry I should clarify @PiFLYON. I should say "$$anonymous$$AC-simple" (I dont find anything simple on a $$anonymous$$AC)... because its a totally different beast to the rest of existence.
Hehe I guess you are right -if we would be "hackers" we wouldn't use mac os after all ;)
Since it is the audio hook that is preventing the computer from going to sleep, one way of doing it is simply to turn off the audio in Unity.
I just tried this, using the Activity Monitor to check as suggested above. Toggling audio in unity (simply by pressing the audio button at the top of the Scene view) changes the "Yes" to "No" in the Activity Monitor's "Preventing Sleep" column.
Of course, this still requires you to remember to do something when you leave your computer, but something that's quite easy and considerably less drastic than quitting Unity.
Further investigation suggests that the above is at best an intermittent solution. Please read on for something more reliable...
I have now been experimenting with the pmset stuff that meat5000 posted about. Running pmset -g assertions does indeed show that the audio daemon is preventing both system and display from going to sleep, and that these assertions were created for Unity.
So, the answer seems to be to kill the audio daemon.
To do this, you can run ps -ef | grep coreaudiod in a terminal to get the pid of the daemon process, and then kill -9 <pid> (or sudo kill -9 <pid>) to kill it.
If you watch your Activity Monitor when you do this, you should see the offending "Yes" change to "No". If you do the ps command again, you'll see that coreaudiod has restarted, but the pmset command no longer shows those sleep-preventing assertions.
However, as soon as you bring focus back to Unity, it once again tells the audio daemon that it wants to prevent sleep; "No" turns back to "Yes", and the pmset output shows the assertions again.
So if you want to use this, make sure you do it right before leaving the computer and crucially, without accidentally giving focus back to Unity.
Nice trick ! But I can't try this right now, I will let someone try this and check if it works. Just to be clear : you mean the little speaker above the scene, not the "$$anonymous$$ute Audio" above the game view ?
Yes that's what I meant. However, I am now not so sure. Like I said above, I tried it before posting as an answer, and literally watched the "Yes" turn to "No" and back several times. But now it doesn't seem to be doing that. So I don't know what's going on. $$anonymous$$ight have to downvote myself :)
And FWIW, the "Disable Unity Audio" checkbox in Project Settings -> Audio $$anonymous$$anager isn't doing anything either.
I'm just experimenting here by the way, since I put my computer to sleep myself (much as I love the environment, I have work to do).
I don't seem to be able to downvote my own answer or add another answer, so I have edited the above with what appears to be a more reliable (though considerably more fiddly) solution,
You can probably add a second answer still by converting from comment. Dont downvote yourself, you dont deserve that!
I just tried it here - and it would have been a great solution - but sadly I have always audio muted in the scene view - but the column still shows "preventing sleep: yes" :(
The other work around by killing the process which causes it seems a bit too harsh - I think unity should simply fix the audio device shutting down correctly if someone is turning off the audio at the scene view for example.
Or maybe there is a way to disable audio globally as a "prevent sleep" device in mac?
In iTunes you can see the correct behaviour because as soon as you pause audio the colum changes the state. Just not in unity - something is keeping the audio always on - I also reported an issue already to them - if they publish it in issue tracker we can start upvote it.
Which potentially "great solution" are you referring to? This seems more like a comment/reply than an answer.
Yeah sorry I guess I put it wrong here - still pretty new to this community stuff (but look I was able to fix it) :) So yes I was referring to your suggestion - which sounded very reasonable - but sadly didn't work (as you found out by yourself already) :)
You're certainly right that in an ideal world Unity wouldn't cause this problem and these kind of workarounds wouldn't be needed. Personally I don't think the killing the daemon solution is too difficult in itself (and could be put into a single shell script if one could be bothered); the real problem is that one is likely to forget to do it.
Yep I think that is the main issue - you leave your mac shortly and surely you will forget to use the shell script. I wonder if there is a possibility to disable this specific audio daemon globally on a mac. I mean even if audio is running from itunes etc. I would not $$anonymous$$d going to sleep - since then I am usually also working on the mac :)
For completeness it's worth also pointing out that it's only sleeping as a result of the user being idle that is being prevented here. So another workaround (which is actually what I do myself as I don't want my computer sleeping unless I tell it to) is to put the computer to sleep explicitly. I use hotcorners for this (in Settings->Desktop).
Though it is not working, thank you Bonfire for these investigations. It's definitively a bug that Unity should correct on $$anonymous$$ac as it is not a problem on PC. (Of course, Unity does not prevent the user to put the $$anonymous$$ac to sleep manually but automatically).
Sure, it's just it occurred to me having done all that writing, that the whole thing is pointless. If there's something you have to remember to do before you leave the computer, in order to allow it to sleep, then you might as well just remember to put it to sleep :)
From what I've been reading, there doesn't seem to be a way to prevent coreaudiod from being able to add these assertions at a system level; Apple choose to give this authority to app developers and not to end users. People had this issue with Spotify, and it was only Spotify that could fix it.
Yeah I have written them and they even acknowledged the problem - but it looks like they have ignored it. They said to me even if its telling that the mac doesn't go to sleep it goes to sleep (!!!??)! Which is a wrong assumption - it is just turning off the monitor but the mac is definitely not going to sleep :(
I guess more people will need to tell them so they finally fix this bad issue. They would just need to turn off all audio devices when idle so that the mac can go to sleep as every other application does.
I noticed this issue initially as I dock my $$anonymous$$acBook Pro with two external monitors and found that none of the displays ever turn off when I leave my machine unattended. I first noticed after leaving for well over an hour and realizing it never slept. So as we are on to something here and I really want to leave my machine docked with Unity open but not active, here is some additional testing/results I have done.
Case 1: On battery, No external screens, Energy Saver-> Turn display off after: 1 $$anonymous$$ute, A handful of normal apps open: Finder, Settings, $$anonymous$$ail, Safari, $$anonymous$$essages, Ter$$anonymous$$al
Result: Screen turns off after specified time.
Case 2: Same as Case 1, Unity open
Result: Laptop does not sleep, however the screen does turn off. Logs do not show that the machine entered a sleep/wake state.
Case 3: Unplugged, on battery, Two external screens, Energy Saver-> Turn display off after: 1 $$anonymous$$ute, Same apps as Case 1: Finder, Settings, $$anonymous$$ail, Safari, $$anonymous$$essages, Ter$$anonymous$$al
Result: Laptop sleeps, external displays turn off due to no input
Case 4: Same as Case 3, Unity now open
Result: Laptop does not sleep, no displays are turned off
Case 5: Connected to power, Two external screens, Same apps as case 1
Result: Laptop sleeps, external displays turn off due to no input
Case 6: Same as case 5, Unity now open
Result: Laptop does not sleep, no displays are turned off
So what about Case 2, when the screen turns off but the unit does not sleep? I found a useful command for ter$$anonymous$$al on stackexchange.com Source: https://apple.stackexchange.com/questions/52064/how-to-find-out-the-start-time-of-last-sleep
pmset -g log|grep -e " Sleep " -e " Wake “
This will actually show all of the sleep/wake state history. I would run this after each time it appeared to sleep to confirm if my machine did indeed sleep or not. The only time it appears to sleep and doesn’t is when Unity is open and no external monitors are attached. Otherwise with external monitors it will show that it does not sleep. Not sure if this may also mean there is a bug in Apple’s code somewhere as it’s inconsistent behavior for Case2.
I submitted a bug for this issue a little while ago and recently got a reply back. I was informed my bug was a duplicate of a known issue and they gave me a link to the item in the issue tracker which can be found here:
https://issuetracker.unity3d.com/issues/editor-is-preventing-mac-os-from-entering-sleep-mode-automatically
