An update. I closed all my background apps (HWiNFO, MSI Afterburner, Discord) and the Audio Controller is still preventing the CPU from going to sleep:
Is there a way I can find out which process or service is keeping it active? Could this be an issue with the Realtek audio software?
Do you have a browser tab with media in it maybe?
If you really want to dive into it, looks like Windows Performance Analyzer is the tool for diagnosing modern standby: Using Windows Performance Analyzer to analyze Modern Standby issues | Microsoft Docs
No browser running.
Thanks for the WPA suggestion, running a trace now.
I ran the trace but I’m not sure what to look for. This is a ~2.5h sleep session after a fresh boot with all my startup programs exited, so I’m sure that I’m not playing or recording any audio. SleepStudy still shows 100% active audio controller.
Here’s one of the graphs. Anywhere else I should look?
I’m out of ideas. But the WPA looks neat so I’ll try it on mine tomorrow if you haven’t figured it out by then.
This isn’t the right solution for this, but I am curious what happens with that if you uninstall the Realtek audio driver and use the Windows default HDA driver.
Thanks, I’ll give that a shot!
Yes, that seems to have worked!
It is still red, but 1%/h is much more in line with expectations! This is the cause of the red for those curious:
EDIT: Another, longer session (2.6%/h):
Thanks for helping debug this! We’ll dig in on the Realtek audio driver to see if we can replicate this and understand what is happening.
So I did a clean install of Windows 10 21H1 on a 512GB AData SX8200 Pro (hardware revision unknown) then installed the Framework driver package (2021_07_08) and the latest ADK.
Running SleepStudy resulted in a 5% drop in battery after an hour with the same Realtek HD Audio as the top offender. Switching to the Microsoft audio driver removed the HD Audio as an offender.
Weirdly though, I’m still seeing a 5% drop per hour even though the top offenders list looks all green now. It’s consistent too across multiple tries.
I think maybe the culprit is the SX8200 Pro from what I can glean from the WPA trace analysis. It spends almost the entire sleep cycle at D0 (normal power state) instead of dropping to a low power state. But maybe that’s normal, I don’t have another SSD to try a Windows install on.
Adding some more datapoints here from my own anecdotal experience.
powercfg /SleepStudy confirmed that the laptop was active for 6.5 hours and discharged 96%. I haven’t had a chance to dig into this deeper yet.powercfg /a reports the same sleep states for me as @feesh mentioned here. I also have the Framework-provided drivers installed.P.S. I’m happy to open a separate thread, but it feels appropriate to group these here.
@obfuscurity If SleepStudy says active then it didn’t properly enter standby mode. Double check your lid-close action settings (Start > type “lid” > Change what closing the lid does)
Or put it to sleep using (Start > power icon > Sleep) to be sure you’re putting it to sleep.
@feesh Right, I can see that it didn’t enter standby. As I mentioned, I haven’t had a chance to investigate further. All of my lid settings remain set to sleep.
Is there a way to check that the lid close sensor is activated? Do the side LED’s indicate that it is going to sleep? Or back to active?
With my old MSI I can at least peak into the closing lid and see if the screen is turning off… And it has external LED’s for power indicator.
FYI another user reporting sleep issues with the Realtek driver
This is fantastic seeing all the responses directly from the team, keep up the good work fellas!
So I wanted to uninstall the Realtek driver, but I can’t seem to get it done. Every time I uninstall and reboot, Windows is reinstalling the Realtek driver instead of the Windows generic audio driver.
For now I’m having to hibernate always, as the device is basically on while in standby, and I don’t want to risk overheating in the laptop bag. The good thing while we wait for a solution? Hibernation is incredibly fast. I’m thinking about remapping the lid close action to trigger hibernation for the meantime.
What I did was go to Device Manager > Device Properties > Driver > Update Driver > Let me pick from a list…
Then select the Microsoft driver from there. That said, hibernation on Windows works well so considering the buggy nature of Modern Standby it probably makes more sense to use that.
Ok, I was literally doing the same but instead of update, uninstall. I’ll try that, and see if there is an improvement. I’d like to use the driver intended for the hardware just to make sure we are getting the performance out of the device, but sound design isn’t something I’m trying to accomplish on the laptop, and so I think the windows generic will work in the meantime.
Regarding the modern standby: I think it is brilliant honestly. If it really works the way it was detailed here. Regular standby with immediate resume until the battery has lost 5% and then hibernation. With how fast the Framework hibernates and resumes from hibernate, I think it is perfect. I do wish we could have the lid open action trigger a power on, similar to a thinkpad. All in good time I imagine. I love this thing.
I’d prefer to have S3, but Intel removed S3 from Tiger Lake. The Modern Standby to hibernate behavior is nice in theory, but I’d feel uncomfortable using it unless it’s demonstrated to be rock solid reliable so the laptop doesn’t turn on while in a bag.
Not a knock against the Framework team though, even Dell and Lenovo seem to be struggling with getting Modern Standby working 100% perfectly on their 11th gen laptops.