I am working on a Windows 10 application that plays audio in the background. What I would like to be able to do is allow the computer to still go in to Sleep Mode while the audio is playing (as in, Power & Sleep Settings, Sleep after XX minutes). And by this, I mean stop playing the audio and go to Sleep (not continue playing while in Sleep). Is this even possible? Searching online hasn't been fruitful, as I can pretty much only find information on how to prevent Sleep, not enable it.
Running powercfg.exe /requests shows the audio playback is indeed preventing sleep:
SYSTEM:
[DRIVER] Realtek High Definition Audio (...)
An audio stream is currently in use.
I am currently using the IAudioClient and IAudioRenderClient interfaces for playback, via client->Start(), renderClient->GetBuffer(). I could switch to a different API if necessary. However, whatever I use needs to allow other applications (VLC, YouTube, Windows sounds, etc.) to play audio as normal at the same time.
My application is always running on the system I'm using it on, and I simply want the system to be able to go to Sleep at the set system timeout. I also need to apply this exception to my application only - if other applications are playing audio that would prevent Sleep, the system should not Sleep.
Are there any Windows API calls that can make Windows ignore my application playing audio and still let the system go into Sleep Mode?
What you are asking for is not possible today. When the system goes to sleep, it essentially means that the processors in your system stops executing any instructions and powers down. Although this is not like shutting down the system, it is very close to it. All the devices connected to the processors are also powered down to save the battery/power consumption.
UWP (or "Metro") apps in Windows 8/10 are frequently suspended when they are not in the foreground. Apps in this state continue to exist but no longer consume CPU time. This change seems to have been introduced to improve performance on low-power/storage devices like tablets and phones.
Please can I ask, what is the most elegant and simple method to detect an app in this state?
I can see 2 possible solutions at the moment:
Call NtQuerySystemInformation() and the enumerate each process and each thread. A process is "suspended" if all threads are in the suspended state. This approach will require a lot of code and critically NtQuerySystemInformation() is only semi-documented and could be removed in a future OS. NtQueryInformationProcess() may also offer a solution with the same problem.
Call GetProcessTimes() and record the counters for each process. Wait some time (minutes) and check these again. If the process counters haven't changed then assume the process is suspended. This is a hack and I may get shot down for even thinking of it.
Jim
The second one (GetProcessTimes() … wait … and check these again.
If the process counters haven’t changed then assume the process is suspended)
is less reliable.
If a process is waiting for input (e.g., keyboard, mouse, or network)
and not getting any, it will use very little CPU time
and will appear to be suspended by this approach.
I'm a hobbyist programmer and have written a small application using Python3 and Gtk3.
It has two threads in it. One is a simple clock showing current time and updating the GUI every minute. The other is a countdown timer which can be started and stopped (the thread is killed with a flag on pause, and a new thread created on start). Both threads are daemons and neither interacts with the other.
It is working perfectly in linux.
In Windows it freezes / locks up, even when I haven't started the timer (i.e. only the clock thread is active). Windoze complains: "Python.exe is not responding".
My initial question is just whether it is safe to use threads in Windows. Or perhaps it is not a good idea to use GTK3?
Has anyone else experienced something like this?
This is my first windows question so apologies if this is obvious or badly worded.
I have a touch screen station that runs Opera in Kisokmode (http://www.opera.com/support/mastering/kiosk/) which is great and works perfectly.
I want to be able to monitor the Opera process and relaunch it if it crashes or is closed.
Can anyone give me some direction on how this can be done, or is there any out-of-the-box software that can do this for me?
There are some software to monitor processes and restart them if they are killed:
http://www.knas.se/Applications/Restarter.aspx
http://drinkprog.com/kiwi/
Just one of the ways to implement such software would be:
1. Open a handle of the target process that needs to be monitored, using OpenProcess API with SYNCHRONIZE access right.
2. Wait infinitely on that handle using WaitForSingleObject or WaitForMultipleObjects APIs.
3. If the process exits or gets killed, then wait would be signaled (with return code WAIT_ABANDONED or WAIT_OBJECT_0).
4. Close the handle. Restart process and repeat the above steps.
When Mac OS X goes to sleep, due to closing a laptop or selecting "Sleep" from the Apple menu, how does it suspend an executing process?
I suppose non-windowed processes are simply suspended at an arbitrary point of execution. Is that also true for Cocoa apps, or does the OS wait until control returns to the run loop dispatcher, and goes to sleep in a "known" location? Does any modern OS do that, or is it usually safe enough to simply suspend an app no matter what it is doing?
I'm curious, because allowing sleep to occur at any moment means, from the app's perspective, the system clock could suddenly leap forward by a significant amount. That's a possibility I don't usually consider while coding.
Your app is interrupted exactly where it is that moment if the CPU is actually currently executing code of your app. Your app constantly gets execution time by the task scheduler, that decides which app gets CPU time, on which core, and for how long. Once the system really goes to sleep, the scheduler simply gives no time to your app any longer, thus it will stop execution wherever it is at that moment, which can happen pretty much everywhere. However, the kernel must be in a clean state. That means if you just made a call into the kernel (many libC functions do) and this call is not at some safe-point (e.g. sleeping, waiting for a condition to become true, etc.) or possibly holding critical kernel locks (e.g. funnels), the kernel may suspend sleep till this call returns back to user space or execution reaches such a safe-point before it finally cancels your app from the task scheduler.
You can open a kernel port and register for sleep/wake-up events. In that case, your app will receive an event, when the system wants to go to sleep. You have several possibilities. One is to reply to it, that the system may progress. Another one is to suspend sleep; however, Apple says certain events can be suspended at most 30 seconds, after that, the system will just continue, whether your app likes it or not. And finally, you can cancel it; though not all events can be canceled. If the system already decided it will go to sleep, you can only suspend this by at most 30 seconds or allow it at once, you cannot cancel it. However, you can also listen to an event, where the system asks apps, if it is okay to go to sleep now and there you can reply "no", causing a sleep to be canceled.
The difference between "Is it okay to sleep" and "I'm planing on going to sleep" is: The first one is sent if the power saving settings are applied, that is, if the user has not moved the mouse or typed anything for the time configured there. In that case the system will just ask, if sleep is okay. An app like Apple's DVD Player will say "no", because most likely the user watches a DVD and thus doesn't interact with the computer, still no reason to go to sleep. OTOH, if the user closes his Mac Book, apps are not asked, the system will go to sleep for sure and just informs apps, that have now up to 30 seconds to react to it.
Wake-up events can also be quite interesting to catch. E.g. if your system wakes up, open files might be inaccessible (an external drive has been unplugged) or network sockets won't work any longer (network has changed). So you may re-init certain app parts before using them and running into errors that are more or less expected.
Apple's page regarding catching these events.
It depends on your app.
If you are interacting with external systems (think networking or doing something over usb/firewire,etc) then it might be affected. An application running on OSX gets to run for a limited time ( max 10ms ) , after which it is interrupted by the kernel which schedules a new process from the process queue to run on the CPU. This is transparent for the application , which "thinks" that it runs all the time on the CPU. Thus , a transition to sleep is no different - apart from the time jumping ahead.
If you need to be aware that there was a transition to sleep mode please refer to this tech note which details how to receive notifications about the state change : Registering and unregistering for sleep and wake notifications
I believe it will just suspend all apps wherever they happen to be.
Remember, this happens all the time anyway. Applications are constantly suspended and resumed due to context switching. So, really, the clock could jump between any 2 instructions in your app, though usually not in a noticable/significant way.
If the OS waited for the app to return to some main loop you could run into situations where applications cause the sleep to hang. If they're doing a lot of work and not returning to the run loop dispatcher they would prevent the machine from going to sleep. That wouldn't be very good. :)
And if you set the time it also appears to leap forward to the running programs. Nothing special either.
Check out this Wikipedia article. Cavver is correct in stating that things like network connections may time out, and thus those services may be interrupted.