Windows: headphones/output device powers off during recording

[abduznik]

Description

On Windows, my headphones (output device) turn off partway through a recording, even though I'm actively speaking into the microphone the whole time.

Root cause (traced through the code)

Windows audio capture lives in electron/native/wgc-capture/src/wasapi_loopback_capture.{h,cpp}. Both the microphone and system-audio paths open WASAPI capture streams:

• Mic: WasapiLoopbackCapture::initializeMicrophone() → initialize(WasapiCaptureEndpoint::Microphone, ...) (wasapi_loopback_capture.cpp:222-265) opens a plain capture-mode IAudioClient on the default capture endpoint.
• System audio: same initialize(), but for WasapiCaptureEndpoint::SystemLoopback it resolves the render endpoint (the headphones/speakers) and initializes it with AUDCLNT_STREAMFLAGS_LOOPBACK (wasapi_loopback_capture.cpp:247-255) — this reads what's already playing, it does not write to the device.

There is no IAudioRenderClient anywhere in the codebase, and no mic→speaker monitoring/passthrough. So the app never writes any PCM to the output device during a recording — it only ever reads from it via loopback capture.

Because the app never opens a render/playback stream on the output device, the render endpoint may look idle to Windows throughout the recording, even while mic capture and loopback capture are both running. That likely lets one of Windows' own power/priority controls on the device kick in and shut it off mid-recording.

I haven't pinned down which exact Windows setting is responsible — it's one of these (need to verify against the code path above):

• Device Manager → the device → Power Management tab → "Allow the computer to turn off this device to save power" (may also show as "Continue running on battery power" vs. "Disable automatically to save power" depending on Windows version/device).
• Sound settings → the device → Advanced/Properties → Exclusive Mode → "Allow applications to take exclusive control of this device" / "Give exclusive mode applications priority" — if some other app or the OS takes exclusive control, other endpoints can get suspended.

This is unrelated to the existing Linux/PipeWire "wrong headphone jack" device-selection bug referenced elsewhere in the code (#404) — that's about picking the wrong input device, not this Windows output-power/priority issue.

Workaround for now

Try disabling power-saving on the device in Device Manager (Power Management tab), and/or disabling exclusive-mode priority for other apps in the device's Advanced properties in Sound settings.

Proposed fix

Open a silent (or near-silent) WASAPI render stream on the same output device for the duration of the recording, alongside the existing loopback capture. Continuously writing to it — even silence — should keep Windows treating the endpoint as actively in use, regardless of which exact setting is currently causing the drop.

Environment

• Windows
• Recording with microphone enabled

---

I'd like to work on this — can I pick it up?

[EtienneLescot]

@abduznik of course you can pick it up, go ahead ;-)
Thanks!

[EtienneLescot]

Thanks for the detailed write-up — the code reading checks out. I verified it: initialize() is the only WASAPI path, AUDCLNT_STREAMFLAGS_LOOPBACK is set only for SystemLoopback (wasapi_loopback_capture.cpp:241-249), and there is no IAudioRenderClient anywhere. With mic only — the default config, since both toggles start false (useScreenRecorder.ts:237,242) — there is genuinely no stream of any kind on the render endpoint for the whole take.

The direction is right and has precedent: NVDA merged "Play silence to keep audio device awake" (nvaccess/nvda#16099, fixes #14386) with exactly this design, and soundkeeper / keep-audio-alive exist for this. Use IAudioRenderClient::ReleaseBuffer(frames, AUDCLNT_BUFFERFLAGS_SILENT) — the audio engine treats the packet as silence regardless of the data values, so there is nothing to memset.

Before the code, though, we need the mechanism. Three candidates give three different answers, and "silent stream" only fixes two of them: USB selective suspend (device level), audio-engine/endpoint idle (endpoint level), or the headset's own firmware auto-power-off. If it is the third, silence may not count as "playing" on some headsets, and the fix would not help. Could you answer these three?

1. Is the microphone the same physical device as the output (same headset), or a separate mic? If it is separate, the keep-alive target is the default render endpoint and nothing about the mic selection is relevant to it.
2. Does it happen with system audio enabled, disabled, or both?
3. At the moment it drops, does the endpoint disappear (unplugged / DEVICE_STATE_NOTPRESENT), or stay present and simply go quiet?

Instrumenting the helper with IMMNotificationClient (OnDeviceStateChanged / OnDefaultDeviceChanged) or a GetDeviceState poll behind an env flag turns "the device powers off" into a timestamped event correlated with the take — that is the evidence the PR needs. Worth knowing on our side: technical-documentation/architecture/recording.md:72 already records that WASAPI loopback delivers no packets while nothing is playing, which is consistent with your theory.

Three things to build in from the start:

• Exact digital silence, not "near-silent". Anything non-zero is audible in the room and gets recorded by our own loopback when system audio is on.
• Lifecycle. Target the default render endpoint, started with the take and stopped with it. main.cpp has five to six stop sites (1366, 1380-1381, 1411-1412, 1454-1455, 1586-1589) — add a single helper rather than a third call at each one, and register it as a named [stop-timing] step, since that is how that file's shutdown gets diagnosed. Initialize(SHARED) failing because another app holds the device exclusively must be non-fatal, and an endpoint invalidated mid-take must not end the recording. A OPENSCREEN_WGC_DISABLE_AUDIO_KEEPALIVE=1 kill-switch (same convention as OPENSCREEN_WGC_ENABLE_DXGI_INPUT) is what lets you A/B this on your own machine and produce before/after evidence.
• Surface the loss. Today, if the device dies mid-take, captureLoop prints to stderr and exits, and AudioMixer::mixLoop fills silence on the clock forever — the track is dead from that instant on and nothing tells the user. That is the same class of failure as fix(recording): advance the audio timeline on the clock, not on the data #406. Please emit {"event":"warning","code":"audio-device-lost",...} following the microphone-defaulted / webcam-unavailable pattern (nativeWindowsCaptureStop.ts:108,121, the tests in nativeWindowsCaptureStop.test.ts, and the toast in useScreenRecorder.ts:1204-1208). Note those are read at start (handlers.ts:2674-2680), so say whether you read yours at stop or add a live notice. This also matters because it is the only part of the change a maintainer without your headset can verify: unplug the device mid-recording and watch for the notice.

Verification — CI is Linux-only, so none of this can be covered there:

• The existing real-helper harnesses must stay green: npm run test:wgc-mic:win, test:wgc-mixed-audio:win, test:wgc-audio-timeline:win.
• A new scripts/test-windows-*.mjs shaped like test-windows-audio-timeline.mjs, playing tones at known instants, is the way to prove the mic track is continuous and undamaged. Silence proves nothing here — the mixer fills a dead source with silence, so only missing tones are evidence.
• Record once with system audio on and confirm the system track stays digital silence, since the keep-alive writes into the same endpoint the loopback reads.
• Rebuild with npm run build:native:win before testing: electron/native/bin/win32-x64/ is frozen at whenever someone last built it and no normal build refreshes it, so an un-rebuilt dev run exercises the old code path.

Sequencing I would suggest: (1) instrumentation + the identified mechanism, (2) the keep-alive with its kill-switch and lifecycle, (3) the audio-device-lost warning. One honest caveat up front: if the mechanism turns out to be the headset's own firmware timer, the right end to this issue may be a troubleshooting note rather than code. Windows only — please leave macOS and Linux alone, their audio paths are separate.

[abduznik]

Thanks for the thorough review — answers to your three questions, from my own hardware (Corsair headset connected via wireless USB dongle):

1. Same physical device: yes, the microphone is on the headset itself — same device as the headphones, connected via the one wireless dongle.
2. System audio state: disabled. I only had the microphone enabled (selected as default input) — system audio/loopback capture was off. So this is the exact "mic only, nothing touches the render endpoint" case from the code reading — no stream of any kind on the render endpoint for the whole take.
3. Device state at drop: it fully disconnects — I hear the headset's own disconnect sound, consistent with it being powered off/dropped rather than just going quiet while still present.

Given mic and headphones share one physical device behind one dongle, I think this points more toward USB selective suspend on the dongle (or the headset's own idle/auto-off firmware) rather than a separate render-endpoint-only power state — since if it were purely "render endpoint looks idle," I'd expect the device to stay enumerated and just mute output, not fully disconnect with the audible drop sound. I haven't yet ruled out the firmware-timer possibility you flagged, which the silent-keep-alive approach wouldn't fix.

Given that, happy to follow your suggested sequencing: instrumentation first (to get a real timestamped signal on why the device state changes) before committing to the silent-stream fix, since a full disconnect leans away from "pure endpoint idle" and toward either USB selective suspend or firmware auto-off. I'll hold off on further code until we've nailed down the mechanism — will report back with IMMNotificationClient/device-state instrumentation results.