Local checkpoint - NOT for public release. Ed: don't add continuous background checks
(they've piled up before) - reuse the disconnect/reconnect mechanism the main app uses.
Replaced the 5s packet-flow health poll with AudioDeviceChangeNotifier - the SAME
event-driven watcher the main window uses. It fires only when a device is added/removed/
changes state or the default changes (nothing polls, nothing accumulates - it's a single
registered COM callback, disposed with the host). While the service intends to send, that
event re-opens capture, covering: the audio stack finishing coming up at boot, a device
plugged/unplugged, and the audio service restarting. Debounced (a hot-plug fires a burst).
Also dropped the per-tick Resume retry: now one start attempt per app-absence, then the
device watcher drives any re-open. The only remaining periodic thing is the tiny 1s
presence-token check for the app-yield (a mutex probe - allocates nothing, accumulates
nothing). Gate 25/25.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Answers "what if it looks for sound
devices before their services are up?"
Two layers now:
- depend= Audiosrv/AudioEndpointBuilder (prior commit) makes Windows start the service
only once the audio services are running.
- Self-heal in the run loop: while it should be sending, if no packets have flowed for
~5s then no capture is actually running (endpoints not fully ready at boot, a device
dropped, or the audio service restarted) - it re-opens the capture. And while NOT
sending it already re-tries every second, so a slow-to-appear audio stack or a device
that returns later is picked up automatically.
So even if the service races ahead of the endpoints being fully enumerated, it keeps
retrying/re-opening until audio actually flows, rather than sitting silent. Gate 25/25.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. First increment of the send-only
Windows service feature (design in memory/project_remsound_service).
THE SPIKE PASSED: the send engine runs fully headless (no window, no message
pump) and streams, proven by a real self-test — the one genuine unknown that
gated the whole feature. Also proves the app-yield model end to end.
What's in this increment (all headless, all tested, 19/19 gate):
- AppConfig: ServiceProfileName + ServiceLoggingEnabled (machine-wide).
- InteractivePresence (Core): the cross-session app-yield token. App holds a
Global\ mutex for its lifetime; the service checks it and yields while an
interactive app is present, resuming when it closes OR crashes (OS frees the
mutex). Name-parameterised internal seams for isolated testing.
- ServiceSendHost (App): loads a send-only profile and streams it to its peers,
WASAPI-only, no ASIO/receive. ApplyProfile/Suspend/Resume + a RunLoop that
drives them from the presence token with a settle delay. v1 sends to direct
peer addresses (LAN/port-forwarded); NAT/relay discovery stays the app's job.
- Program.cs: the interactive app now acquires the presence token at startup so
a future service yields to it.
- Tests: "Service app-yield token" (held=present, released=absent) and "Service
send host (headless stream + yield)" — streams a captured device to a local
receiver over loopback, verifies start/suspend/resume, then drives the full
RunLoop against the token (held=suspended, released=resumes-and-flows).
Still to come (later increments): the --run-service entry + Windows-service
registration, the Service menu, the 3-tab config dialog, updater integration,
docs. None user-facing yet, so nothing deployed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
EdnunpandClaude Opus 4.8