Ultrasoldier

system

Properties1
tagssystem, windows, power_plan, power_management, c_states, core_parking, usb_selective_suspend, pcie_aspm, zen4, audio, wasapi, real, exclusive_mode, latency

10 min read

System

Overview

This note covers the changes made to Windows itself on this PC, as opposed to a specific peripheral. Right now that’s two areas: the power plan, and the Windows audio path. Hardware choices like headphones live in hardware.

The system is a desktop with an AMD Ryzen 7 7600X (Zen 4), running Windows 11, with AMD’s chipset power-management package installed.

Power Plan

A Windows power plan controls more than screen brightness and sleep timers. It also decides whether idle USB devices and PCIe links can power down, whether disk and sleep timers can interrupt a session, and how the CPU handles idle cores. That last part is where “just max everything out” stops being obviously correct.

Current settings on this system. A custom scheme called “Ultrasoldier Latency” (GUID 425b55c3-5295-47c7-924d-4b194f3a9f63), duplicated from Windows’ built-in High Performance scheme and set active.

SettingCurrent value
USB selective suspendDisabled
PCIe Link State Power ManagementOff
Hard disk turn off afterNever
Sleep after / Hibernate afterNever
System cooling policyActive
Maximum processor state100%
Minimum processor stateLeft at the scheme’s inherited default, not forced to 100%
Core parking (CPMINCORES / CPMAXCORES)Left unwritten, not forced off

This plan was applied on request, as a deliberate owner override. A separate, benchmark-first PC-tuning project classes both a custom power plan and the High Performance switch as “test before applying.” That project’s own records note this decision plainly. It was not an oversight.

USB and PCIe Power Saving

treactis

(Drafted from the settings log. Rewrite in your own words and add anything you actually noticed.) I turned off USB selective suspend and PCIe Link State Power Management in the custom plan. I also stopped Windows from powering down the USB root hub and volume-key interface of my USB DAC.

Scientific Evidence

USB selective suspend and PCIe Active State Power Management (ASPM) let an idle device drop into a low-power state to save energy. Waking it back up costs time. This is documented Windows and PCI-SIG behavior, not folklore.

For a mouse, keyboard, or audio DAC that needs to respond instantly, that wake-up cost is a real, if usually small, source of latency. Disabling power saving for those devices removes it. On a desktop, the cost is only a slightly higher idle power draw, which barely matters.

Disk and Sleep Timers

treactis

(Drafted from the settings log. Rewrite in your own words.) I set the disk timer and the sleep and hibernate timers to “Never.”

Scientific Evidence

These timers don’t reduce latency by themselves. What they do is prevent an interruption if the system sits idle mid-session, for example while alt-tabbed on a loading screen. A desktop has no reason to sleep during active use, so there’s no real downside.

Minimum Processor State and Core Parking

treactis

(Drafted from the settings log. Rewrite in your own words.) I left minimum processor state and core parking at the scheme’s defaults instead of forcing them to their maximum. One catch showed up while doing this. The High Performance scheme I duplicated from already keeps CPMINCORES at 100, which means all cores stay unparked. So in practice my cores are fully unparked anyway. My intent (leave idle behavior at its normal default) and the actual result (every core awake) don’t match yet.

Scientific Evidence

This is the least settled part of this note.

On modern Ryzen, the CPU uses the power headroom freed up by idle cores to boost the active cores higher and longer. Idle cores reach that low-power state through C-states (deep idle states). Keeping every core artificially awake competes for the same thermal budget. This is a documented feature of how AMD’s Precision Boost works. But no source was found that measures the size of this effect specifically for Zen 4.

A tech-comparison site testing Ryzen 5000 and 7000-series systems found that High Performance improved gaming FPS by only about 3.5% on average across 15 games. The best case was about 8%, in CS2. It also ran 10–15°C hotter at idle, 5–8°C hotter under load, and drew roughly 30W more at idle. The site concluded that Windows’ own Balanced plan already works well on Ryzen 5000 and newer, because AMD’s chipset driver handles the scheduling. This is one source with unpublished test methods. It’s directionally useful, not a precise number. It also didn’t test minimum processor state or core parking as separate variables.

An older official AMD source points the other way. AMD’s original 2017 “Ryzen Balanced” plan, made for first-generation Ryzen, explicitly disabled core parking, because Windows parked cores too aggressively on that generation. That’s a much older CPU with different firmware, so it isn’t a direct contradiction of the Zen 4 reasoning. But it does mean “core parking off is bad” isn’t a rule for every Ryzen generation.

Net practical read: the uncontroversial settings (USB, PCIe, disk and sleep timers) are worth maximizing. The CPU idle settings are uncertain for this generation. The honest choice is to leave them at the base scheme’s behavior, not to force them to their most aggressive-sounding value.

How Strong Is the Power Plan Evidence

Documented mechanism, not in question: USB selective suspend, PCIe ASPM, and CPU C-states and core parking all exist and behave as described, per Windows and AMD documentation.

Real numbers, single source, unpublished methods: the 3.5%-average and 10–15°C-hotter figures come from one tech-comparison article, not an independent lab benchmark.

Older and generation-specific: AMD’s 2017 plan disabled core parking for first-generation Ryzen. It’s named here because it’s an official AMD position that doesn’t fit a clean story.

Not found: any independent or AMD source that isolates and measures core parking or minimum processor state for Zen 4 under sustained gaming load.

Audio

Audio latency on a PC is a chain of separate links, and each link has its own fix:

  1. Game mixing. How quickly the game itself produces the sound. No OS or driver setting touches this.
  2. Windows audio engine buffering. Windows’ audio engine (WASAPI) collects sound into a buffer before passing it on. A bigger buffer resists glitches, but adds delay. REAL and exclusive mode, below, work on this link.
  3. Driver and output hardware. Onboard audio with a generic or manufacturer driver, an external USB DAC, or a USB headset with its own DAC. Each has its own latency floor.
  4. Transport to the headphones, if wireless. A 2.4GHz dongle or Bluetooth. This link is hardware, not a Windows setting, so it’s covered in hardware.

The most common mistake in guides on this topic is treating “reduce sound latency” as one setting. Fixing link 2 does nothing for link 4, and the other way around.

This system’s default output is a USB DAC dongle (WL HUAN IEM) running on Windows’ built-in generic USB Audio 2.0 (UAC2) driver. No vendor driver exists for it.

REAL and the WASAPI Shared Buffer

treactis

(Drafted from the audio latency experiment log. Rewrite in your own words and add how it feels in play.) I installed REAL v0.2.0, running in the tray and starting automatically with Windows. On my USB DAC, the buffer dropped from 480 samples (10 ms, the Windows default) to 336 samples (7 ms, the device’s minimum). I checked this from REAL’s own readout, not just by trusting that it was running. There was no crackling during setup. I haven’t yet checked for crackling during a real match with the CPU busy.

Scientific Evidence

Windows’ audio engine uses roughly a 10 ms buffer by default in shared mode. Almost everything uses shared mode, because it lets the game, Discord, and a browser play sound on the same device at once. When one application asks for a smaller buffer through the right Windows interface, Windows switches every application on that device to the smaller buffer (pchardwarepro’s WASAPI guide). On a supporting driver, this can go as low as about 2.7 ms at 48 kHz.

REAL is a small utility that does exactly this. It opens an audio stream asking for the driver’s smallest buffer and keeps it open, so every other application benefits too. This is a real, documented mechanism. REAL didn’t invent it. It’s just a simple, always-on way to trigger it.

The cost is crackling risk. A smaller buffer has less headroom. If the CPU is briefly busy and can’t refill it in time, you hear clicks or dropouts. Any small-buffer approach carries this tradeoff.

REAL is MIT-licensed and its source code is public, so it’s possible to check what it actually does.

Audio Enhancements

treactis

(Drafted from the audio latency experiment log. Rewrite in your own words.) I turned off Windows audio enhancements on my DAC. The registry value Disable_SysFx is now set to 1.

Scientific Evidence

Windows “audio enhancements” include the equalizer, virtual surround, loudness equalization, and Windows 11’s spatial sound. They’re an extra processing step before output. They add latency for no competitive benefit in a shooter (MakeUseOf’s piece on Windows 11 audio enhancements).

You turn them off per device, in Settings → System → Sound → [device] → Properties, or with “Disable all enhancements” in the older Sound control panel. Unlike the buffer change above, this has basically no downside for a gaming setup.

Exclusive Mode

treactis

(Not yet written. Have you tried letting a game take exclusive control of your audio device? If so, what happened with Discord?)

Scientific Evidence

Windows has a per-device setting, “Allow applications to take exclusive control of this device.” It lets one application skip the shared audio engine completely. That can cut latency further than the shared-buffer trick, down toward the 4–5 ms range some WASAPI guides mention.

The cost: while one application holds the device, others generally can’t play sound through it. If Discord or another voice app runs during play, that’s a real tradeoff. It needs testing per application, not an assumption that it helps.

How Strong Is the Audio Evidence

Documented mechanism, not in question: WASAPI’s shared-buffer negotiation, exclusive mode, and the extra processing step added by audio enhancements are all things Windows does as described.

Single self-report: REAL’s creator reported a drop from 40.3 ms to 31 ms on their own system. The mechanism is real. That number is one person’s measurement.

Disputed: REAL’s reliability on Windows 11 in general. The issue tracker has both “works” and “does nothing” reports with no clear resolution. On this system it’s confirmed working.

  • hardware — the hardware side of audio: wired vs. wireless vs. Bluetooth transport, and IEMs vs. headsets.
  • aim — the general background on how local system latency affects aim.

Sources

Graph View

Backlinks