Ed: ~1s was still too slow; the capture must hear the boot audio from the instant
it starts — and no hot check-check-check loop.
Event-driven instant path: hook the Windows session-created notification on the
default render device (the same AudioSessionStartWatcher that catches a per-app
send from its very start). An app setting up an audio session fires it BEFORE its
first sound plays — at the boot lock screen that's LogonUI / the Windows tune /
NVDA arriving. New session + this capture has never heard audio -> re-open right
then, so the re-attached capture is listening from the first note. Zero polling.
- CRITICAL filter: our own silence keepalive also creates a session on that device
— reacting to our own pid would re-open in an endless loop. Filtered.
- Re-open is now capture-only (sender stop -> rebuild specs -> start): network
presence stays up, peers see no discovery blip. Shared by both self-heal paths
(instant session-kick + the 500ms meter watchdog, which stays as the backstop in
case the session notification doesn't cross sessions pre-login) and rate-limited
+ capped in ONE place so the two paths can't stack re-opens.
- Callback hops to the thread pool — never tears down audio objects from inside an
audio notification.
- Watcher recreated per apply (re-points at the current default device), disposed
on suspend/dispose.
Gate: 39/39.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
EdnunpandClaude Opus 4.8
4d49d5554e