none
Windows 8 connected standby vs desktop audio player application

    Question

  • Hi.

    While testing my audio player software (a win32/x86 desktop app) on a Windows 8 tablet with connected standby feature, I ran into the following scenario:
    Requests to keep the system up - via SetThreadExecutionState() or PowerSetRequest() - are disregarded - the machine goes to sleep after the idle timer expires and my application becomes suspended.
    This makes my software useless, unless the user specifically alters system-wide settings to make it run (disable sleep timers). Which is harmful in other ways as it would drain the battery if left running.

    Further research led me into the following:
    Desktop Activity Moderator:
    http://msdn.microsoft.com/en-us/library/windows/desktop/hh848040(v=vs.85).aspx
    New "PowerRequestExecutionRequired" request type:
    http://msdn.microsoft.com/en-us/library/windows/desktop/dd405534(v=vs.85).aspx 

    PowerRequestExecutionRequired sounds useful for certain tasks, unfortunately it's useless for me as my process gets suspended some 5 minutes after the screen turns off.

    Solution?
    Since all desktop apps seem to be equally affected by this, I checked what the desktop version Windows Media Player does on the offending machine, and behold, it mitigates the problem by keeping the screen on (PowerRequestDisplayRequired) all the time even when playing just audio.
    While this sounds extremely harmful for battery life - as we could as well run with screen turned OFF because the user is just listening to music in a non-interactive fashion, I'll be forced to use PowerRequestDisplayRequired too on the affected machines, or else my app essentially doesn't work. It's not like I'm abusing the API because Windows Media Player seems to do exactly the same.
    In other words, a new shiny technology which was meant to limit power use is forcing me to eat more power.

    I hope there's a better way around this (other than turning my app into a Metro app which is currently not an option). Any constructive replies are welcome.


    • Edited by deathly Wednesday, April 24, 2013 9:20 AM
    Wednesday, April 24, 2013 9:17 AM

All replies

  • Friday, May 02, 2014 9:06 AM
  • This is completely expected and documented behavior. All desktop apps are suspended during this type of standby.  Think again: Why a user may ever want to listen to music during CS? CS is a state when the machine looks turned off, so it is natural that it won't play any music. it is sleeping. Playing music is a user-oriented activity.   If you'd like to further discuss the player behavior , consider the Win8 music forum 

    -- pa



    • Edited by Pavel A Friday, May 02, 2014 9:32 AM
    Friday, May 02, 2014 9:23 AM
  • Pavel: you're missing the point.  Certainly the user does not want to listen to music during CS, but the user *does* want the machine to not go into CS when he or she is listening to music - or running a simulation, or any other task that happens without continuous user interaction.

    Sunday, May 04, 2014 3:48 AM
  • Pavel: you're missing the point.  Certainly the user does not want to listen to music during CS, but the user *does* want the machine to not go into CS when he or she is listening to music - or running a simulation, or any other task that happens without continuous user interaction.

    I second this. It's a full-featured x86 Windows 8.1 Pro machine, I want to have an option to keep it alive and run my desktop applications uninterrupted, even when running on battery. I have this option for my laptop, which battery life is much shorter.
    • Edited by Noseratio Sunday, May 04, 2014 7:19 AM Quote
    Sunday, May 04, 2014 7:17 AM
  • Ok I got this. So, Win8 on a CS capable machine ignores PowerRequestExecutionRequired and it will not prevent entering CS? PowerRequestDisplayRequired can block CS entry, but consumes more power.  Is this a correct summary of the problem?

    P.

    Sunday, May 04, 2014 2:57 PM
  • Ok I got this. So, Win8 on a CS capable machine ignores PowerRequestExecutionRequired and it will not prevent entering CS? PowerRequestDisplayRequired can block CS entry, but consumes more power.  Is this a correct summary of the problem?

    P.

    Yes, this is a correct summary, besides I haven't tried PowerRequestDisplayRequired as I would not consider it a solution. The screen should stay switched off while the tablet is doing some background work. 

    I posted a few more details here, while trying to answer a related question. Frankly, I consider this a major design flaw, I do hope I'm wrong and there's still a way to get the desired behavior.



    • Edited by Noseratio Tuesday, May 06, 2014 3:17 AM spelling
    Monday, May 05, 2014 1:23 AM