Feature request: toggle for TeamSpeak inhibiting monitor sleep/standby

[koitsu]

The TeamSpeak client on Windows inhibits the ability for a display/monitor to go into standby (power save/sleep) mode. This "quirk" has existed since I can remember. IIRC, it behaved this way on XP, and it still does to this day on Windows 7 x64.

POWERCFG.EXE -REQUESTS

...shows no inhibition requests, which means the methodology being used is probably a legacy WM_SYSCOMMAND handler that returns 0 when SC_MONITORBROADCAST is received, thus inhibiting the system from being able to put a monitor into standby. The Win32 code responsible for this would look something like this:

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
  switch (uMsg)
  {
        case WM_SYSCOMMAND:
        {
                switch (wParam)
                {
                        case SC_MONITORPOWER:
                                return 0;
                }
                break;
        }
  }
  return DefWindowProc(hWnd, uMsg, wParam, lParam);
}

But obviously I don't know what methodology you folks are using (there are several on Windows), but obviously are via some means. :-)

I'd like to request the ability to toggle this feature, through a checkbox somewhere in the Settings GUI. I can think of no reason that TeamSpeak, simply because it's running, should stop my displays from going into standby.

Thank you.

[Chris]

My monitors turn off just fine, after the timeout specified in Power Options -> Turn off the display with TeamSpeak client running.

As for the system itself, it won't turn off with active audio streams, which means you'll have to disable playback / capture profiles for the system to go into standby with the client running.

[koitsu]

I don't have a way to prove to you that both of my workstation screens *do not* turn off when TeamSpeak is running on Windows 7 Ultimate x64 SP1. This is not a laptop, it's a self-built desktop system. How would you like me to prove it?

For me it's as easy as the client running. I don't even have to join a server or a channel. Instant I quit the client, the display sleep timer seems to start ticking again. In other words: display standby set to 1 minute, run TS, wait several minutes (displays don't turn off), exit TS, wait 1 minute, displays turn off.

I have a feeling your system standby inhibition code may be what's inhibiting monitor standby. I fully acknowledge that in this situation system standby should be inhibited, but *display* sleep/standby should not.

Example, while connected to a TS server + in a channel, where display standby isn't happening, all I see is this (the Realtek audio driver inhibiting system sleep makes sense, but note under DISPLAY):

C:\Users\jdc>powercfg -requests
DISPLAY:
None.

SYSTEM:
[DRIVER] Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0887&SUBSYS_1458A182&REV_1003\4&6e312be&0&0001)
An audio stream is currently in use.

AWAYMODE:
None.

I should add the above output from POWERCFG -REQUESTS is the exact same situation I see with many other voice chat applications (Skype, Discord, etc.) -- yet those do not have this problem. It is absolutely specific to the TS client.

I've reviewed documentation from Microsoft about Power Availability Requests and it is strongly implied that system sleep inhibition and display standby inhibition are two separate things (one must call Win32's PowerSetRequest() twice, once with POWER_REQUEST_TYPE set to PowerRequestDisplayRequired, and another time set to PowerRequestSystemRequired). Reference for that: http://download.microsoft.com/downlo...yRequests.docx

I do not have any power request overrides in place.

But POWERCFG will only show things using the Vista-and-newer Power Management API; it will not give insight into legacy methodologies like the code I provided. So if TeamSpeak is using the WM_SYSCOMMAND method, then POWERCFG is useless for analysis on my part. I have a strong feeling TS is using legacy methodologies to remain compatible with older OSes (which is fine).

Also, my previous code had a bug in it: switch (wParam) should have been switch (wParam & 0xfff0) -- something very easily overlooked in MSDN docs, and that bug can apparently cause a lot of different problems.

[X3r0X]

I can't confirm this either. All my monitors switch to standby after the specified time when TeamSpeak is running.

I had a problem with vJoy (Virtual GameController, known for preventing standby) and TobiiEyeX once, but never TeamSpeak.