2.0.3 MuseScore Prevents Mac (10.11.4) from Sleeping

• Apr 26, 2016 - 05:57

Energy consumption is rather high in the background, but more importantly I noticed that MuseScore is the only application on my machine preventing sleep. Not sure if there's a feature preventing this, or if it's possible, but definitely a hinderance to an old Dual Xeon Tower (can't be pretty on an electric bill).

Attachment Size
preventsleep.jpg 74.47 KB

Comments

Does it happen with a particular score, or with any score? What if you have no score open in MuseScore, does the issue also occur in that case?

What if you disable all Audio interfaces under Preferences > I/O. and check again if it goes into sleep mode.

Thank you for testing.

In reply to by TheGuitarShawn

Also try closing the Navigator and see if that makes a difference. Some find even just resizing it helps with the CPU background activity issue. Not sure why some people seem to affected by this but most of aren't - some subtle hardware or OS version difference perhaps.

Generally, yes, once good steps to reproduce a bug are found, it should go to the issue tracker. Meanwhile, this is a good place to hash things out.

In reply to by Marc Sabatella

Yes this is occurring in all cases. With and without scores, with and without multiple scores, changing audio interfaces, navigator in view or not. Always shows in activity monitor that the app is preventing the computer from sleeping; and can confirm this behavior.

My Windows 10 system will not hibernate if MuseScore is running, whether or not a score is open, because the system sees MuseScore as "an audio stream... currently in use." I discovered that by going to

https://lifehacker.com/5924010/how-to-find-out-whats-keeping-your-compu…

It instructed me to run Command Prompt as an Administrator, and type :

powercfg -requests

It looks like this:

C:\WINDOWS\system32>powercfg -requests

and returned these results:

DISPLAY:
None.

SYSTEM:
[DRIVER] High Definition Audio Device (HDAUDIO\FUNC_01&VEN_10EC&DEV_0662&SUBSYS_103C1495&REV_1001\4&148a919f&0&0001)
An audio stream is currently in use.

AWAYMODE:
None.

EXECUTION:
None.

PERFBOOST:
None.

ACTIVELOCKSCREEN:
None.

So, the only thing interfering with automatic sleeping or hibernating is the "audio stream" being output all the time MuseScore is running. When I closed MuseScore and re-checked, the results were all "None."

In MuseScore I edited the preferences, changing I/O from "PortAudio" to "JACK audio server." Leaving MuseScore running, I re-checked "powercfg -requests," and again, all the results were "None."

So, there are two ways to prevent MuseScore from interfering with hibernation on my Windows 10 system:
1. Quit (Exit) MuseScore when I'm done working with it
2. Switch MuseScore's I/O from "PortAudio" to "JACK audio server." I assume this will prevent me from hearing playback through my current setup.

For Mac, that same lifehacker site also has instructions for Mac that will tell you if a device is preventing sleep, and what process that is. I would assume, though, it's the same story. Maybe something can be done in a future release of MuseScore that will turn off the audio stream after a period of unuse.

In reply to by WStites

Are you perhaps actually playing a score? There shouldn't be any output otherwise. And my computer running Windows 10 doesn't have any particular problems going to sleep if MuseScore is running but not doing anything. Although I do have other issues with sleep on my computer from time to time, and I guess it worth further investigation to see if there is any connection. But certainly, I leave MuseScore running almost all the time, and usually the computer sleeps normally.

In reply to by Marc Sabatella

Thanks, Marc. Actually, my computer will go to sleep with MuseScore running, but it won't hibernate. The problem persists even with no score open (and thus nothing playing). My guess is that MuseScore keeps the "audio stream" open, even though no signal is present. And again, it's only when the I/O is set to "PortAudio." Perhaps you and Eric could perform the Command Prompt check I described, while MuseScore is running but not playing anything, and tell me if you get the same result "An audio stream is currently in use." That would be a huge sanity check for me.

In reply to by ericfontainejazz

Thanks, Eric. It might be a bug in my install, as you suggest. But I have no idea how to determine that. Perhaps you and Marc could perform the Command Prompt check I described, while MuseScore is running but not playing anything, and tell me if you get the same result "An audio stream is currently in use." That would be a huge sanity check for me. Also verify that your I/O is set to "PortAudio," as mine is.

In reply to by WStites

@WStites, powercfg give me message "An audio stream is currently in use" both when I have musescore open but not playing and when musescore is playing. I should note that this itself isn't unusual and shouldn't be a cause for concern, because when musescore initializes, it tries to open up an audio stream, and will keep that open as long as musescore can. Note that when you switch to jack, musescore fails to open an audio stream during initialization, which is to be expected if you don't have jack installed. So it seems to me the fact that an audio stream is open is NOT the exact cause of musescore being unable to sleep. Rather I suspect there is some bug eating the CPU somewhere. I'd be curious if you could inspect your CPU monitor and see if musescore is eating a core while idle. Because normally musescore should be using next to nothing of the cpu while it is idle. BTW, here is the output of my powercfg (identical when I am playing the score and when I'm not):

powercfg -requests
DISPLAY:
None.

SYSTEM:
[DRIVER] USB Audio Device (USB\VID_0D8C&PID_0014&MI_00\6&ffd21c5&1&0000)
An audio stream is currently in use.
[DRIVER] Legacy Kernel Caller

AWAYMODE:
None.

EXECUTION:
None.

PERFBOOST:
None.

ACTIVELOCKSCREEN:
None.

In reply to by ericfontainejazz

I really appreciate the time and effort you've given this.
On my machine, when MuseScore is open but idle, it's using 0.1-0.3% of CPU, according to Task Manager.
When it's playing a very simple score, it uses 0.6-0.7% of CPU.

Please keep in mind that the Command Prompt thing we did came from a website named "how-to-find-out-whats-keeping-your-computer-from-going-to-sleep," and that when "An audio stream is currently in use," my computer won't hibernate, and when that system request is absent, it will hibernate. And it's almost certain now that it's MuseScore generating that request.

Let me also underscore that my computer will go to sleep with MuseScore running. What it won't do is hibernate, which is a full power down.

It's not a major hardship for me to save my work and Exit MuseScore before walking away. I posted mainly to share with TheGuitarShawn and others what I've learned about why some of us have this sleep/hibernate issue. That said, I sure would like to find a solution to it.

In reply to by WStites

since your cpu usage is low, that means my theory about you having a CPU eating bug was wrong.

I understand that on your computer when "an audio stream is currently in use" that you can't hibernate. But as I said that doesn't happen on my windows 10 machine, which is able to hibernate musescore even when that command on my command prompt indicates that "an audio stream is currently in use". So we haven't nailed down the precise cause yet.

Googling https://www.google.com/search?q=windows+"an+audio+stream+is+currently+in+use"+hibernate leads me to https://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider… where was solved in response 1 by having the user to add a manual override so that the particular audio stream wouldn't block hibernation, using the command:

powercfg -REQUESTSOVERRIDE DRIVER "High Definition Audio Device" SYSTEM.

Since your powercfg reports the name of driver is "High Definition Audio Device", I think this will work for you.

Note, this is simply a "workaround". Maybe there is something musescore can do to ensure that its audio stream will never cause hibernation to block. But I don't know and don't want to research that at the moment.

In reply to by Marc Sabatella

Here's what I think we've established so far:

--Like many applications and devices, MuseScore generates a system power request for "[DRIVER] High Definition Audio Device," (HDAD driver). It remains "in use" (or open) as long as MuseScore is running with its I/O set to "PortAudio".

--Depending on how a Windows system is configured, that power request with its open driver could prevent the computer from going to sleep and/or hibernating. (Per TheGuitarShawn's posts, this may also be true for Mac systems.)

--MuseScore-Windows users can manually set their computer to override the driver's power request, if necessary, by running the elevated Command Prompt (running as Administrator) and typing (or copy/pasting):

      powercfg -REQUESTSOVERRIDE DRIVER "High Definition Audio Device" SYSTEM

(Note that "High Definition Audio Device" must be in quotes.) Sleep/hibernation will then be enabled. If you change your mind, you can remove the HDAD override by typing:

      powercfg -REQUESTSOVERRIDE DRIVER "High Definition Audio Device"

(Note that "SYSTEM" is omitted from the command.) MuseScore (and perhaps other things that use the HDAD driver) will then prevent sleep/hibernation. You can always check which overrides have been set by typing:

      powercfg -REQUESTSOVERRIDE

There's probably more to this sleep/hibernate issue. These findings are all consistent with my original post, and none of this strikes me as a "bug" in MuseScore. It is, however, an opportunity for future development, where MuseScore might either:

  1. Upon installation, set the override or do whatever else is appropriate to allow sleep/hibernation on all platforms, regardless of previous system configuration.
  2. Close the HDAD driver after a period of unuse.
  3. List this as a known limitation.

Again, thanks to Eric and Marc. I'm new to the MuseScore Forum. Please advise as to how to get this issue into the hopper for future development.

In reply to by WStites

"--It may be that installing certain third-party sound apps or sound hardware devices automatically and invisibly sets an override which prevents the HDAD driver from preventing sleep/hibernation – in other words, allowing it. (My computer has never had any other such apps or devices.)"

This is a very interesting theory...I wouldn't be able to prove whether or not this is true unless I start with a fresh install of windows (I'm not going to do now!). But I think you might be correct. I suppose I could try right now disabling any pre-existing over-ride, and then try to hibernate...

"1. Upon installation, set the override or do whatever else is appropriate to allow sleep/hibernation on all platforms, regardless of previous system configuration."

I think this is not a bad idea. I'd have to look online for a particular windows & mac API which would allow this to be easily set by musescore, either upon install or on each run.

"Close the HDAD driver after a period of unuse."

Naw...I think this fix will be too involved. Would have to set timers for turning off, and then would have to re-initialize audio upon next playback.

In reply to by ericfontainejazz

I'm on my windows machine with musescore open, and type powercfg -REQUESTSOVERRIDE then I get:

[SERVICE]

[PROCESS]

[DRIVER]

Which is indicating to me that there has never been any override set in the first place. So that discredits the theory that the reason why I can still hibernate on my machine is because some other program overrode the block.

In reply to by ericfontainejazz

That's exactly what I was going to ask you to do next. Hmm. If you're willing, please check your registry at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerRequestOverride
See if you have the DWORD "High Definition Audio Device". Mine is set to 2.

(I edited my last comment to remove the discredited theory, though it's still possible that some third-party installation changes something else somewhere.)

In reply to by ericfontainejazz

Eric, here's what I did:

  1. checked powercfg -REQUESTSOVERRIDE result: [DRIVER] High Definition Audio Device SYSTEM
  2. in Registry, set value of DWORD "High Definition Audio Device" to 0
  3. Restart
  4. checked powercfg -REQUESTSOVERRIDE. result: [DRIVER] High Definition Audio Device SYSTEM (that surprised me)
  5. in Registry, checked DWORD "High Definition Audio Device" value was still set to 0
  6. in Registry, deleted DWORD "High Definition Audio Device"
  7. Restart
  8. checked powercfg -REQUESTSOVERRIDE. result: no overrides
  9. launched MuseScore
  10. in Settings, set hibernation timeout to 1 minute. Result: After 1 minute the display when black; after a mouse move, the computer came back exactly as it was. I think it neither went to sleep nor hibernated. This is probably what it was doing in the first place, and I mistook it for actually going to sleep – my bad. It certainly did not hibernate.
  11. typed powercfg -REQUESTSOVERRIDE DRIVER "High Definition Audio Device" SYSTEM (to set the override)
  12. checked powercfg -REQUESTSOVERRIDE result: [DRIVER] High Definition Audio Device SYSTEM
  13. checked Registry. DWORD "High Definition Audio Device" was restored, with value 2
  14. typed powercfg -REQUESTSOVERRIDE DRIVER "High Definition Audio Device" (to remove the override)
  15. checked powercfg -REQUESTSOVERRIDE. result: (no overrides)
  16. checked Registry, DWORD "High Definition Audio Device" was deleted – no sign of it
  17. (repeated steps 11-16 with same results)
  18. in Registry, created new DWORD "High Definition Audio Device", set value to 2
  19. checked powercfg -REQUESTSOVERRIDE result: [DRIVER] High Definition Audio Device SYSTEM
  20. after 1 minute of no activity, the computer went into hibernation (power completely off) as expected.

So what I'm seeing is apparent perfect correlation between the presence of the DWORD in the registry and the override reported by powercfg -REQUESTSOVERRIDE. Deleting one automatically deletes the other; creating one automatically creates the other. When both are present the system will hibernate; when both are absent, it will not. You indicate that neither are present on your computer, yet it hibernates. FWIW, my OS:

Microsoft Windows 10 Pro, version 10.0.16299 Build 16299 (totally up to date with the latest updates)

In reply to by WStites

OK, so what we know is:

  • setting an override for musescore's audio stream on a system which can't hibernate due to presence of musescore's audio steam will thereby allow the system to hibernate.
  • However, some systems are able to hibernate while musescore's audio stream is open even without setting an override.

I have a theory that it is particular audio devices/drivers that prevent the computer from sleeping if the device is open. I'm curious if you have a USB audio device...maybe if you have musescore output through a USB device instead, might be able to sleep without an override.

In reply to by ericfontainejazz

Back in June of last year I bought this amazing and powerful HP computer just bristling front and back with USB ports. The plan is to use it for music recording and mixing. But I haven't yet been able to afford the USB audio interface I want. So all that's plugged in to all those holes is a keyboard, mouse, USB charging cable, and a puny WiFi adapter. Nothing for audio. And I don't own anything I could try to plug in.

We've probably investigated this as far as we can afford to. I'm satisfied with how the override works currently. If later on I want to stream media and my computer hibernates after 15 minutes, I might then regret having set the override. And that's why it's a workaround, not a real solution. But I'm deeply grateful for your help.

Same thing happening to my system. I have a MacBook Pro (15", 2016) with Catalina 10.15.5 installed. When MuseScore is active it will not allow the system to initialize the screen saver, sleep, or turn off the display. When I switch from Port Audio to Jack Audio Server it does work as a previous commenter mentioned.
I'm a python developer. I don't have time this week or early next week but have added it to my task list for next weekend to take some time to look at the code and see if I can find where the problem is coming from.

Do you still have an unanswered question? Please log in first to post your question.