USB audio interface keeps dropping out on Windows 11? It's probably power management

A recording session that dies mid-take is worse than one that never starts. Mine kept dying the same way: Roland Rubix 24, Ableton Live 12 in ASIO mode, and a few minutes in — sometimes ten, sometimes three — Live throws a "device error", the interface vanishes from the audio settings, and whatever take was rolling is gone.

If you're seeing this pattern on Windows 11 — works fine at first, then drops out after minutes of use or idle — the odds are good that nothing is broken at all. Windows is turning your interface off to save power, and your DAW experiences that as a hardware failure.

Here's how I confirmed it and fixed it, with a script you can run.

First, rule out the driver

The obvious suspect is the driver, so check it first. For the Rubix series, Roland explicitly says the generic Windows USB Audio Class 2.0 driver does not work correctly — you need their vendor driver. Check whether it's actually installed:

pnputil /enum-drivers | Select-String -Pattern 'roland|rubix' -Context 4,4

In my case the official driver (1.0.7, WHQL-signed) was already there and the device reported a healthy status. So the driver wasn't it. If yours is missing, install it from the manufacturer's site first and see if the problem disappears — but don't be surprised if it doesn't, because the real culprit is usually one layer down.

The real culprit: three layers of USB power saving

Windows 11 has three separate mechanisms that can cut power to a USB audio device, and any one of them is enough to kill your session:

1. USB selective suspend — a power-plan setting that lets Windows suspend USB devices it considers idle. An audio interface that isn't currently streaming counts as idle.
2. Hub-level power management — every USB root hub and hub has its own "Allow the computer to turn off this device to save power" checkbox in Device Manager. If the hub your interface hangs off gets powered down, the interface goes with it.
3. Enhanced Power Management on the device itself — a per-device registry flag (EnhancedPowerManagementEnabled) that lets Windows put that specific device into a low-power state. This is the classic fix for USB audio gear that "disconnects randomly", and it's the one most people never find.

On my machine, selective suspend was enabled on both AC and battery power, every hub had power management on, and the Rubix had no override set. Three loaded guns pointed at the session.

It's worth knowing the backdrop, too: Windows 11 24H2 and 25H2 both shipped with documented USB audio regressions (devices timing out when idle, a January 2025 patch that broke external DACs outright), and the new MIDI stack has been rough on older vendor drivers. Power management is the part you can fix yourself today.

The fix, as one script

Run this in an elevated PowerShell (right-click → Run as administrator). Replace the $vidPid value with your own interface's — find it with Get-PnpDevice | Where-Object FriendlyName -match 'YourInterfaceName'.

#Requires -RunAsAdministrator
$ErrorActionPreference = 'Stop'

# 1. Disable USB selective suspend (AC + battery) on the active power plan
powercfg /setacvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0
powercfg /setdcvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0
powercfg /setactive SCHEME_CURRENT

# 2. Turn off "allow the computer to turn off this device" on all USB hubs,
#    and on the interface itself
$vidPid = 'VID_0582&PID_01E0'   # Roland Rubix 24 -- replace with yours
$targetIds = @(
  Get-PnpDevice -Class USB -PresentOnly |
    Where-Object { $_.FriendlyName -match 'Hub|集线器' -or $_.InstanceId -match $vidPid } |
    Select-Object -ExpandProperty InstanceId
)
$powerMgmt = Get-CimInstance -Namespace root\wmi -ClassName MSPower_DeviceEnable
foreach ($id in $targetIds) {
  $powerMgmt |
    Where-Object { $_.InstanceName.StartsWith($id, [System.StringComparison]::OrdinalIgnoreCase) -and $_.Enable } |
    ForEach-Object { $_ | Set-CimInstance -Property @{ Enable = $false } }
}

# 3. Disable Enhanced Power Management for every known instance of the interface
$root = "HKLM:\SYSTEM\CurrentControlSet\Enum\USB\$vidPid"
foreach ($key in Get-ChildItem $root) {
  $dp = Join-Path $key.PSPath 'Device Parameters'
  if (Test-Path $dp) {
    Set-ItemProperty -Path $dp -Name 'EnhancedPowerManagementEnabled' -Value 0 -Type DWord
  }
}

Then unplug the interface, wait five seconds, plug it back in — the registry flag only takes effect when the device re-enumerates. A reboot is the belt-and-braces version.

Everything here is reversible: set the two powercfg indexes back to 1, re-tick the checkboxes in Device Manager, and set the registry value back to 1.

Verify it actually landed

Don't trust a script that prints "done" — check the state:

# Both indexes should now read 0x00000000
powercfg /query SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3

# Every instance should show EPM=0
Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Enum\USB\VID_0582&PID_01E0" | ForEach-Object {
  $dp = Join-Path $_.PSPath 'Device Parameters'
  if (Test-Path $dp) {
    '{0}: EPM={1}' -f $_.PSChildName,
      (Get-ItemProperty $dp -Name EnhancedPowerManagementEnabled -ErrorAction SilentlyContinue).EnhancedPowerManagementEnabled
  }
}

Two traps I hit on the way

The silent script failure. My first version of the script had comments in Chinese, saved as UTF-8 without BOM. Windows PowerShell 5.1 reads BOM-less files as ANSI, so the multi-byte characters corrupted the parse and the elevated window closed instantly — no error, no log, no changes. If your .ps1 contains any non-ASCII text, save it as UTF-8 with BOM (or run it with PowerShell 7, which assumes UTF-8).

Stale device instances. If you've plugged the interface into different USB ports over time, Windows keeps a registry entry per port (that's why the loop above sets the flag on every instance). Pick one port and stick with it.

If it still drops out

Then you're likely looking at the other layer: the OS itself. Check winver — if you're on 24H2 or 25H2, install the latest cumulative updates, since Microsoft has been patching the USB audio regressions incrementally. Try a rear-panel port straight off the motherboard, and a different cable. And if the interface's vendor driver hasn't been updated since 2017 (looking at you, Rubix), weigh how long you want to keep fighting: interfaces from vendors that ship current Windows drivers are cheaper than lost takes.

Stable audio hardware matters to us for a selfish reason: Joint records into the browser through the same USB stack your DAW uses, and a take that dies from a phantom disconnect is gone no matter how good the software above it is. Fix the power management once, and every recording tool on the machine gets more reliable.