all audio on the desktop went wrong at once. voices tinny and scratchy at normal volume, pure static at low volume. every source — twitch, spotify, everything. cycling the USB speakers (Vanatoo Transparent One — rock-solid hardware, no fancy drivers, no software updates) didn’t help, but killing audiodg.exe (the Windows Audio Device Graph process) always fixed it temporarily. it would come back hours or days later.

this is the story of four wrong answers. we have rewritten this blog post three times because we kept finding “the real answer” and then it kept happening.

wrong answer #1: SteelSeries Sonar APO

SteelSeries GG had auto-updated overnight. the update service threw a “handle is invalid” error. the timing was suspicious.

digging deeper, we found that SteelSeries installs Audio Processing Objects — DLLs that hook into the Windows audio pipeline at the driver level via audiodg.exe. four of them:

  • CNAHIMICAPOMFX CAPTURE (via Sonar.APO.dll)
  • RenderGameApo (via Sonar.APO.dll)
  • DTS SFX APO (via dtsapo64.dll)
  • DTS MFX APO (via dtsapo64.dll)

the nasty part: these stay loaded even when Sonar is “off” in the UI. the toggle controls the Sonar application, not the APOs already injected into the audio engine. they’re registered through a PnP driver (oem70.inf) and loaded every time audiodg starts.

we disabled the APO devices and the virtual audio device via PowerShell, restarted audiodg, set up a scheduled task to keep them disabled at boot. audio worked. problem solved!

…until it wasn’t.

wrong answer #2: USB selective suspend

the static came back with the sonar APO completely disabled and confirmed not loading. no APO DLLs in audiodg’s module list at all.

next suspect: USB selective suspend — a power management feature that lets the USB controller power-cycle ports to save energy. on a desktop with no battery, there’s zero benefit, but it can interrupt isochronous USB audio transfers if the controller suspends and resumes at the wrong moment.

disabled it via powercfg. still happened.

wrong answer #3: AMD noise suppression

AMD’s chipset drivers install an AMD-Dynamic Audio Noise Suppression software component. another invisible audio processing layer. disabled the device, added another scheduled task.

static came back again.

wrong answer #4: SPDIF passthrough formats

at this point we had all APOs disabled, USB power management off, AMD noise suppression gone, no USB errors in event logs, DPC latency clean, audiodg module list completely clean. and then we discovered something: the TE7022 USB DAC (SPDIF output) had DTS Audio and Dolby Digital auto-selected as supported formats.

these are SPDIF bitstream passthrough modes meant for surround receivers. the Vanatoo speakers can’t decode DTS. when we tested DTS playback from the supported formats tab, we got exactly the static we’d been hearing. aha! unchecked both formats. problem solved!

…for about a day.

the static came back with only the 48kHz sample rate selected — no passthrough formats at all. the DTS discovery was a red herring within a red herring: yes, playing DTS through stereo speakers produces static, but that wasn’t what was triggering the intermittent issue.

the actual pattern

here’s what we know for certain after eliminating everything else:

  1. the audio pipeline is completely clean — no third-party APOs, no processing, generic USB audio driver, solid hardware
  2. something in audiodg.exe’s shared-mode mixer state corrupts over time
  3. clicking “Test” in the sound control panel’s Advanced tab instantly fixes all audio — without restarting audiodg, without restarting any streams, without changing any settings
  4. the test tone forces Windows to reinitialize the shared-mode audio session on that endpoint, clearing whatever corruption built up in the mixer

the system has a lot of audio clients running simultaneously — discord, game streaming (sunshine/steam), browser streams, spotify, razer software. something in how these apps open and close audio sessions likely corrupts the mixer state over time.

the workaround

click Test in Sound → Speakers → Properties → Advanced. that’s it. one click and everything works again.

we could automate this — play a silent tone through the endpoint periodically — but honestly, clicking a button once every few days when it happens is fine. the important thing is knowing what to click instead of restarting audiodg or rebooting.

what we actually learned

every wrong answer was still worth investigating:

  • the sonar APOs really were invisible middleware that persists when users think it’s off — we keep them disabled
  • USB selective suspend really is pointless on a desktop — disabled everywhere
  • AMD noise suppression was an unnecessary audio processing layer — gone
  • SPDIF passthrough formats on stereo speakers are a bad idea regardless

but the actual bug is in Windows’ audio engine. the shared-mode mixer accumulates some kind of corrupt state under sustained multi-client use, and the only fix is poking it to reinitialize. we stripped the entire audio stack down to bare metal and the problem persists.

sometimes you debug every layer of the audio pipeline and the answer is “yeah, audiodg just does that sometimes. click Test.” sometimes you rewrite the blog post about it three times. ≽^•⩊•^≼