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.
