The 15s silence-pulse trigger was far too slow (Ed: the boot tune would be over
before the first check) and silence alone was always a weak signal — a quiet
machine and a deaf capture look identical from inside the stream.
New detector: read the endpoint's OWN output meter (IAudioMeterInformation
.MasterPeakValue) every watch tick, independently of our capture stream, and
compare it with what the capture is hearing. Device audibly playing (meter >=
0.003) while the capture has heard only silence since it opened = the capture is
provably DEAF -> re-open it immediately so it re-attaches to the live audio graph.
- Service loop tick 1000ms -> 500ms; deafness threshold is TIME-based (450ms of
continuous divergence) so reaction lands ~1s after the first audible sound —
fast enough that the boot tune itself comes through — and a fast test cadence
can't trip it (a healthy capture hears real sound within ~200ms).
- Zero churn risk: a quiet machine reads quiet on BOTH sides, so healthy captures
never re-open (the old design would have re-opened 3x on any quiet stint).
- Frozen callbacks (2s+) still re-open regardless of loudness.
- Ladder: max 3 re-opens per stint, 2s spacing, ends at the first real audio
heard; refilled on Resume and power resume.
- Meter readers swapped per (re)apply, disposed on suspend; per-device catch
absorbs a disposed/invalidated endpoint mid-read.
- 15s pulse is now purely diagnostic and logs capPeak + meterPeak maxima with an
explicit "(DEVICE AUDIBLE BUT CAPTURE SILENT)" flag.
- Decision core (ShouldReopenCapture) pure + pinned by updated self-test.
Gate: 39/39.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Corrected diagnosis (Ed: the machine's OWN speakers audibly play the Windows tune
and NVDA at the boot lock screen — the endpoint is NOT silent): a loopback capture
attached in the first seconds of boot can land on an audio-engine mix the
logon-session audio path was never wired into. Callbacks flow (fed by our own
silence keepalive) but carry none of the audio that is audibly playing, and Windows
fires no device event about it — the previously-shipped device-change reopen never
triggers. Signing in re-plumbs the session audio into the graph, which is why sound
starts instantly with zero change on our side; a capture opened after sign-out
(graph fully live) works at the lock screen, matching Jonathan's reports exactly.
Fix: while sending, the 15s capture pulse now drives a self-heal — if the capture
has heard only silence since it opened (pre-encode peak < 0.001 on every pulse), or
its callbacks freeze, tear down and re-open the capture so it re-attaches to the
live graph. Capped at 3 attempts per sending stint; the first real audio ends the
ladder so a quiet-but-healthy capture is never churned. Ladder refills on Resume()
and on power resume (wake re-plumbs the graph like boot). Every re-open is logged
with the attempt count, so Jonathan's next log shows either "re-open recovered
audio" (fixed) or three silent re-opens (deeper Windows routing issue, and we know
exactly where we stand).
Decision core (ShouldReopenSilentCapture) is pure and pinned by a new self-test.
Gate: 39/39.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Per-app capture (the "foobar alone = no sound" report):
- ProcessLoopbackCapture: take ActivateAudioInterfaceAsync's out operation as a raw
IntPtr (released after completion) instead of a typed interface. The eager RCW cast
of the not-yet-realised operation object threw InvalidCastException / E_NOINTERFACE
and killed EVERY specific-app capture at start.
- CompositeCaptureBackend: single IsPushEligible authority shared by Start,
UpdateSources and the coalesced rebuild. The update paths were missing the
ProcessLoopback exclusion, so switching whole-device -> one app kept the push
backend and fed it "proc:<pid>" (GetDevice ArgumentException).
- PushModeWasapiBackend: loud backstop rejecting process-loopback specs.
- Self-test: lifecycle test now FAILS on an activation error (it previously passed
green with the feature completely dead) + pure routing-rule checks.
Apps-mode UI (Ed 2026-07-16): the "Send all applications" checkbox is GONE from the
main window - applications mode always means picking specific apps; whole-system
audio is devices mode's job. Active list = running apps + any ticked app that is not
running ("(not running)" so it can be unticked); Remembered list = global address
book minus whatever is ticked. In-place list reconcile (no Clear+rebuild) kills the
NVDA double-read of the toggled row. Profile.SendAllApplications stays for the
SERVICE (deliberate divergence - a headless lock-screen sender wants system audio).
Remembered lists now genuinely machine-wide (AppConfig-backed): the settings store is
an intra-process cache, so remembered applications were forgotten on every exit and
remembered peers were per-profile in practice. Both books moved to AppConfig; legacy
per-profile peers are unioned in on profile load; profile save snapshots the global
book back for old-build compat. Cross-instance persistence pinned by self-test.
Service (issue #23): 15s capture pulse (callbacks/bytes/pre-encode peak/frames sent)
while sending - distinguishes "endpoint mix is genuinely silent at the lock screen"
from a pipeline fault, which callbacks alone cannot.
Gate: 38/38.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Remembered peers were already machine-wide for the main app; remembered apps are
now global too (a shared address book across all profiles), so it doesn't confuse
the user with a different list per profile.
- RemSoundSettingsStore.Load/SaveRememberedApplications (global, NOT written into
profile files) mirrors remembered peers. Removed the per-profile
Profile.RememberedSendApplications. Ticking an app in any profile adds it to the
global list (RememberCheckedApps); the per-profile SelectedSendApplications
(the active/ticked subset) is unchanged.
- Preferences -> General now has two buttons at the end, under a 'Remembered
lists (shared across all profiles)' header: 'Clear remembered peers list...'
and 'Clear remembered applications list...', each with a Yes/No confirmation.
Clearing peers refreshes the main window; clearing apps empties the global list.
- Self-test 'Remembered applications list is global + clearable' (round-trip,
case-insensitive dedupe, clear); the dialog accessibility audit covers the two
new buttons (names + mnemonics, no clash). Gate 37/37.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fixes the bug where a ticked app that launched AFTER the profile loaded was
never captured: the 3s reconcile only redrew the list and only ran while you
were looking at it, so it never restarted the audio capture.
Now:
- AudioSessionStartWatcher (RemSound.Sender): hooks the Windows audio-session-
created notification on the default render device, firing the instant an app
opens an audio session (i.e. about to make its first sound). Re-points on a
default-device change. Best-effort; falls back to the poll.
- RefreshSendAppCapture: re-applies the send sources whenever the ticked apps'
running process ids change, driven by both the session watcher (instant) and
the reconcile poll (backstop) — and the poll now runs regardless of which tab
is showing, so a remembered app is caught even when you're not on the list.
- Profile.RememberedSendApplications added (persisted; the two-list UI that
uses it lands next).
- Self-test 'Send-app capture change-detection': the pure signature is stable
while nothing changes and flips when a ticked app opens/closes. Gate 36/36.
Live behaviour (real apps + the session notification) needs on-machine testing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
So that if the service breaks on a machine where nobody enabled logging first
(e.g. a Win7 tester), we still learn WHY:
- New always-on ServiceStore.AppendServiceEvent -> service-events.log in
ProgramData, independent of any logging toggle (like the update log).
- Service menu status-query failure now shows the actual reason IN the status
line (a screen reader reads it) AND records it to the events log, instead of a
bare 'status unavailable' whose reason only went to the off-by-default app log.
- ServiceAction (install/uninstall/start/stop) records request + outcome to the
events log.
- ServiceEntry (the elevated child) logs each verb's start, and CATCHES a
System.ServiceProcess load failure to record its reason before rethrowing (so
the crash file still gets the full stack) — this is the likely Win7 failure.
- 'View service log' falls back to the events log when no runtime diagnostic log
exists, so there's always something to view after any service interaction.
Recap of coverage: hard crashes -> crash-*.txt (always, no setup). Graceful
service failures -> now the events log + on-screen reason (no setup). Gate 35/35.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Checked the service's connection handling against the networking issues that
shaped the main app. The service reused the low-level protocol components
(discovery, heartbeat, listener, sender), so it inherits their behaviour — but
it was MISSING the app's higher-level connection management from
MainForm.RefreshAudioReceivers: it called SetReceivers once with ALL configured
peers and blind-sent forever, even into dead addresses. That's exactly issue #8
(streaming into a peer that's gone) and it ignored issue #15 (retry/recover).
Fix: the service now streams ONLY to peers the heartbeat can reach, drops any
that stay unreachable past a 30s grace window, and re-arms them the moment they
recover — the same logic (and 30s threshold) as the app. Runs on the service's
existing 1s poll tick (no new timer, no background pile-up). Send-only, so no
"actively receiving" carve-out.
- ServiceNetworkPresence.PeerHealthSnapshot() exposes the heartbeat health.
- ServiceSendHost.ComputeArmedEndpoints (pure) + RefreshSendArming, wired into
RunLoopCore.
- Self-test "Service reachability-gated sending": reachable armed, long-
unreachable dropped, grace-window kept, no-data arms all. Gate 35/35.
Coverage of the other networking issues: multi-homed LAN+VPN (#18) is a
receiver-side allow-list fix — N/A to a send-only service, and its sender-side
support (announcing on all interfaces) is inherited from PeerDiscoveryService.
Forced/locked IPs (#17/#7): the service resolves peers literally and never
follows names, so it's inherently "locked" (what #17 asked for). Device
recovery (#5): already built. NOT built: discovery-based name-following (the
app can chase a peer whose IP changes); the service stays on its configured
addresses by design — flagged for Ed to decide if the service needs it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The real cause — from the tester's crash stack, not my earlier (wrong)
System.ServiceProcess theory: ApplySendModeVisibility() is called early in the
MainForm constructor (via ApplyAsioMode), BEFORE the Input/Output tab populates
the send-mode ListBox. On Windows 7 process-loopback is unsupported, so it took
the `!supported` branch and set SelectedIndex on an EMPTY list, throwing
ArgumentOutOfRangeException ("value ('0') must be less than '0'") and crashing
at launch. On Windows 10/11 that branch is skipped (process-loopback IS
supported), which hid it from the gate and from every Win10/11 test.
.NET 10 genuinely runs on the tester's Win7 SP1 box (CoreLib 10.0.826 in the
crash) — so the earlier assembly-load theory was wrong; those Win7 changes were
addressing a non-problem. This is the fault.
Fix: guard the SelectedIndex set with `sendModeList.Items.Count > 0`. When the
list is empty there's nothing to reset (it's created selecting Devices, and this
runs again once the tab is built).
Test: "Main window builds where process-loopback is unsupported (issue #22)" —
forces ProcessLoopbackCapture.IsSupported = false (new ForceSupportedForTest
seam) and constructs the headless MainForm, so a Win10/11 box exercises the Win7
path. VERIFIED it reproduces: with the guard reverted the test fails with the
exact tester exception; with the guard it passes. Gate 34/34.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The capability PROBE (added earlier for feature-detect) constructed a
ServiceController during window construction, which loaded System.ServiceProcess
on EVERY launch. On Win11 that's harmless, but on Win7 it meant the app was
attempting that risky load at startup, surviving only on a catch — too fragile
for a guarantee. Verified empirically: a normal launch was loading
System.ServiceProcess.ServiceController.dll again.
Fix: decide Service-menu visibility with a Windows-VERSION check
(OperatingSystem.IsWindowsVersionAtLeast(10,0)) instead of a runtime probe. A
version check touches no service type, so the service assembly is NOT referenced
at launch on any OS. On Win7/8 the menu is hidden and that assembly is never
loaded; on Win10+ it loads only later, if the user actually opens the Service
menu (already wrapped in try/catch). Feature-detecting on Win7 and keeping Win7
launch-safe are mutually exclusive (you can't test the load without doing it),
so we choose guaranteed launch safety.
- Deleted ServiceCapability (the probe) — now unused.
- Replaced its self-test with "Main window builds without loading the service
assembly (Win7-safe)": constructing the main window must not load
System.ServiceProcess. Verified empirically too: normal launch now loads 0
service modules (was 1).
Gate 33/33.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The send-only service could never be found or connected to — it only pushed
audio blindly to fixed peer addresses, with no beacon and nothing listening.
So a phone could neither discover it nor dial it. This gives the service a real
network presence built from the SAME components the interactive app uses, wired
the same way, so its discovery / heartbeat / NAT-pinhole / relay behaviour is
identical to the app's — which is what makes it "one identity" (both announce
under the machine name and pair through the relay the same way). Works LAN and,
inheriting the app's relay path, across the internet.
New ServiceNetworkPresence (reuses PeerDiscoveryService + AudioReceiver listener
+ HeartbeatService, wired to the host's AudioSender):
- Discoverable: announces send-only under the machine name (LAN broadcast +
unicast to the configured peers for across-the-internet).
- Reachable: binds the well-known audio-port listener; PLAYBACK stays OFF
(send-only never plays received audio — the listener only carries
heartbeat/pairing).
- Pairable: heartbeat pings the peers (opens the NAT pinhole, drives relay
pairing); replies route back on the listener (LAN) or the sender socket
(relay).
Integrated into ServiceSendHost: comes up alongside the sender while streaming,
and — critically — tears ALL the way down to a shell on Suspend (stop
announcing, unbind the port, stop the heartbeat) so the service and the
interactive app never both hold the network. A brief dropout on that handover
is accepted (Ed's call); only one owns the network at a time.
Tests: "Service network presence" (Start binds the listener + comes up; Stop
unbinds to a shell; re-startable). "Service send host" now also asserts the
presence comes up with streaming and drops to a shell on Suspend. Gate 33/33.
NOTE: the live discover/connect/relay path can only be proven by the tester's
phone — the headless tests prove the lifecycle and teardown, not the internet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Tester couldn't see anything under "View service update log" -- that item only
shows the SELF-UPDATE log (written when the service updates itself to a new
version), so with no update it's empty. What he actually wanted is the service's
ACTIVITY log, which records why the service is or isn't sending
("streaming N sources to M peers", "profile has no WASAPI send sources",
"no reachable peers"), but there was no way to open it.
- New Service menu item "View service log" opens the newest diagnostic log in
ProgramData\RemSound\service\logs. If none exists it explains that service
logging must be enabled first (Configure service profile -> Logging), so the
path to getting a log is discoverable.
- ServiceStore.LogsDirectory + NewestLogFile() to locate it (same absolute path
for the SYSTEM service and the interactive user).
- Clarified the update-log "nothing yet" message to point at the new item.
This also unblocks diagnosing the pre-login send issue: enable service logging,
reproduce, then View service log to see the exact reason.
New self-test "Service log discovery": folder resolves under the service dir,
newest .log is chosen, empty case handled. Gate 32/32.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Alt+S didn't open the Service menu because the always-visible "Send my audio"
checkbox already owns Alt+S, and a visible control beats a top-level menu for
the same Alt key. Every letter in "Service" (S/e/r/v/i/c) collides with a
control (Send / Receive / Volume / Connected peers / EQ / ...), so the menu
now uses Alt+J -- unused anywhere in the main window, so it opens reliably from
every tab. Same approach the Record menu already uses ("Record (Alt+&K)").
Kept Send on Alt+S (frequent control) rather than moving it.
New self-test "Menu shortcuts don't clash with controls": builds the main
window and asserts no top-level menu mnemonic collides with any control
mnemonic. The existing coverage audit couldn't catch this -- menu items are
ToolStripItems, not Controls, so its control walk never saw them. Confirms the
other four menus (File/Record/Options/Help) were already clean. Gate 31/31.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replaces the hardcoded "Windows 10 or newer" gate on the Service menu with a
runtime capability probe (ServiceCapability). It tries to load the .NET
service machinery (System.ServiceProcess) and offers the Service menu wherever
that succeeds -- including Windows 7 if the service layer loads there, which is
what Ed asked for ("install on Win7 or above"). If the assembly can't load on
an older/unsupported Windows, the probe catches it and the menu is simply
hidden, so such a machine can never be crashed by it.
Safety by construction: the reference to the service types lives only in the
NoInlining Probe method, so the assembly load is triggered by the CALL from
IsAvailable (inside its try/catch) and is catchable -- not during JIT of the
caller, which would be fatal. The startup path stays service-type-free via
ServiceEntry, so this probe runs only at window construction, never at launch.
Probe uses the parameterless ServiceController ctor: it forces the assembly to
load but touches no service and no SCM. (First cut read .ServiceName on a
made-up name, which actually queries the SCM and threw "service not found" --
the self-test caught that it was hiding the menu on Windows 11 too.)
New self-test "Service capability probe": available + cached + never throws on
the Win10/11 gate runner. Gate 30/30.
Note: this makes the service INSTALLABLE on Win7 wherever the layer loads; it
does not prove the service RUNS there (Session-0 capture on an unsupported
runtime) -- only a real test on the Win7 box can confirm that.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reported: RemSound no longer launches at all on Windows 7 since the
send-only service was added. Cause: RemSoundService derives from
ServiceBase (System.ServiceProcess), and Program.Main called
RemSoundService.RunAsService() directly in its body. The runtime resolves
every type a method names when it JIT-compiles that method -- so the moment
Main was compiled, at the very start of every launch and before any argument
was read, it force-loaded System.ServiceProcess. That assembly won't load on
Windows 7 under the .NET 10 runtime, so Main failed to compile and the app
died with no window. net10 has always been the target, so this was a pure
regression from the service work, not a framework change.
Fix:
- Move the whole service-verb dispatch into a separate ServiceEntry class.
Program.Main now only calls it (a) after a cheap check that uses only
inlined const verb strings, and (b) only when a service verb is actually
present. A normal launch never JIT-compiles anything that names a service
type, so System.ServiceProcess is never loaded. Verified empirically:
a normal launch loads 107 modules, none of them System.ServiceProcess.
- Gate the Service menu to Windows 10+ (OperatingSystem.IsWindowsVersionAtLeast),
mirroring how the "capture individual apps" feature is gated. On Win7/8 the
menu isn't shown and no service code is reachable. Made the status-query
handler defensive too, so a query failure can never crash the menu.
New self-test "Service verb gate": normal launches (no args, --silent,
--profile, --connect, --minimized, --config-dir) are never treated as a
service invocation; all five service verbs are recognised case-insensitively;
and deciding a normal launch loads no service assembly. Gate 29/29.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
New global setting in Preferences -> General, right after "Browse for
profiles folder": a list "Auto-save non-read-only profiles" with Never /
Every 2 / 5 / 10 / 15 / 20 / 30 minutes. When enabled, RemSound periodically
saves the current profile, but ONLY if it is a real saved profile, is NOT
read-only, and has unsaved changes -- and it saves SILENTLY (no save cue,
no confirmation), so it never interrupts the user.
- AppConfig.AutoSaveNonReadOnlyMinutes (machine-wide, 0 = Never = default).
- SaveProfileTo gains a playCue flag; auto-save passes playCue: false.
- MainForm autoSaveTimer + ApplyAutoSaveTimer + ShouldAutoSave guard,
re-applied live when the setting changes in Preferences.
- New self-test "Auto-save non-read-only profiles": options list, AppConfig
persistence, the guard (read-only / blank / unchanged all skipped), and the
timer turning on/off. Gate 28/28.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Ed wants logging for the service updating.
- New ALWAYS-ON update log at ProgramData\RemSound\service\update.log (not gated on the
service-logging toggle - updates are rare but important). It records the full sequence:
* "update detected: newer RemSound.exe (5.3) found, running 5.2 - restarting"
* the restarter's own "stopping" / "service started" (or "START FAILED - <reason>")
* "update complete: now running version 5.3"
The restart PowerShell writes its stop/start outcome itself, so the part that runs AFTER
the old service process is gone - and any failed start - is still captured. A pending
marker set at detection and consumed on the next start closes the loop (its absence flags
a stuck update).
- Service menu gains "View service update log" to open it (friendly message if none yet).
Update log + pending-marker round-trip covered by the isolation self-test. Gate 27/27.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Answers "how will we know if the service
updated itself?"
- The service records its version + start time on every OnStart into ServiceStore
(ProgramData). A self-update restart therefore bumps the version and refreshes the
start time.
- The Service menu status line now shows it: "Service: installed, running — version 5.3,
running since 2 min ago". So you can see the running version at a glance, and a recent
start with a bumped version is the self-update landing.
- Also logged on start ("service: OnStart, version X") for the service log.
Status round-trip covered by the isolation self-test. Gate 27/27.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Ed: an update should tear down the service,
update it, and restart it. It didn't - the updater has no service awareness.
Current (unchanged, verified correct): the auto-updater renames the install files aside
and copies the new ones in, which a running service TOLERATES (no failed swap). The old
version keeps streaming; the new files sit in place.
New: the service now adopts the update itself. Because it runs as SYSTEM (which has the
rights the non-elevated updater lacks), a 45s timer notices when a strictly-newer
RemSound.exe has landed next to it and restarts itself onto the new binary (detached
PowerShell Stop-Service+Start-Service). Loop-safe: only fires on a strictly-newer on-disk
version; any uncertainty (file mid-swap, unparseable version) means don't restart, and
after the restart on-disk == running so it never re-triggers.
Test "Service registration args" now also covers the version-comparison logic (newer =>
restart; same/older/missing => no restart). Gate 27/27.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. A "what else does a service need" pass.
- AUTO-RESTART ON CRASH: DoInstall now sets sc failure actions (restart 5s/10s/then 60s,
reset daily). Without this a crashed service stays dead until reboot - fatal for an
always-on streamer.
- FINDABLE LOGS: --run-service redirects the service's data dir to the machine-wide
ProgramData\RemSound\service location, so its log sits next to its profile instead of
buried in the SYSTEM account's AppData.
- POWER RESUME: the service handles OnPowerEvent and re-opens capture on wake (audio
devices re-initialise after sleep; the device-change watcher usually catches it, but a
resume doesn't always fire an endpoint change, so we re-open explicitly).
- Start/stop already auto-log to the Windows Event Log via ServiceBase.
Test: "Service registration args" now also checks the audio-service dependency and the
auto-restart failure args. Gate 27/27.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Ed: the service profile must never be
reachable except through the Service menu.
Also fixes a real bug: the service runs as SYSTEM, whose per-user data folder is NOT the
interactive user's - so a profile saved in the user's profiles folder (or AppConfig, both
per-user) was invisible to the service. It would have idled, never streaming.
- New RemSound.Core.ServiceStore: the service profile + its settings (logging) live in a
MACHINE-WIDE ProgramData\RemSound\service location - same absolute path for the user
(config dialog) and SYSTEM (service). Moved ServiceProfileName/ServiceLoggingEnabled off
AppConfig (per-user) onto this store.
- ServiceSendHost.FromConfig + RemSoundService now read ServiceStore; ConfigureServiceProfile
saves there (and migrates + deletes any profile left in the old user-folder location).
- Because it's no longer in the user's profiles folder, it can't appear in the startup
picker, File->Open, Recent profiles, or the password manager (all of which read the user
ProfileStore); the reserved-title filter in ListProfileTitles stays as belt-and-braces.
- Password button renamed "Set service profile password".
- New self-test "Service profile isolation": store is under ProgramData, the reserved title
is filtered from the listing, and it round-trips through the machine-wide store.
Gate 27/27.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Ed will test the real install/service and
the sound by hand, so the elevated (admin-only) install/start/stop/uninstall self-test
isn't worth keeping. Removed it and its IsAdministrator helper. The headless service
tests stay (parity, app-yield, send host, registration args) - those run in the gate and
guard the service against drifting from the main app. Gate 26/26.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release.
New self-test "Service real lifecycle" drives the ACTUAL SCM end to end: install ->
report installed -> start -> report running -> stop -> report stopped -> uninstall ->
report gone. Needs admin, so it's OPT-IN via REMSOUND_TEST_SERVICE=1 and skips cleanly
in the normal unprivileged gate. It clears any leftover registration first (DoUninstall
stops a running copy, so a stray from an aborted run can't fail it) and always removes
the service afterwards, even on failure - so it never leaves a service pointing at a
throwaway exe. Run elevated: set REMSOUND_TEST_SERVICE=1 then RemSound.exe --selftest.
The app-yield takeover is already covered headlessly by "Service send host (stream +
yield)"; a full real end-to-end (installed service goes quiet when the app opens) needs
a live peer to observe and stays a manual check. Gate 26 passed, 1 skipped of 27.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Adds a check that a peer with no explicit
port resolves to RemPacket.DefaultPeerDialPort (not the local audio port), guarding the
third audit divergence. Gate 26/26.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Audited ServiceSendHost against MainForm's
send path (Ed: make the service reuse the same code, be just as stable). Three real
divergences found and fixed:
1. ENCRYPTION FINGERPRINT (critical): the host set sender.AudioKey but NOT
sender.AudioFingerprint. The main app (RecomputeAudioCrypto) sets both, and the peer
verifies the fingerprint before accepting a stream - so the service's encrypted audio
would have been REJECTED at the far end. Now derives and sets both from the password.
2. OPUS FRAME: the main app applies EffectiveOpusFrameSamples (the "Small" send rate
halves the Opus frame); the host passed the raw frame, so it would encode differently
than the main app for the same profile. Now reuses MainForm.EffectiveOpusFrameSamples
(made internal - same code, not a copy).
3. PEER PORT: send target fell back to the profile's LOCAL AudioPort; the correct default
is RemPacket.DefaultPeerDialPort (what the main app's manual-peer path uses). Same value
today but the right constant.
Reviewed and OK: sender defaults to WasapiOnly (no SetAudioMode needed); BuildSendSpecs
matches ApplySendSources for explicit-device profiles; default-device changes are covered
by the device-change watcher; direct-send (no relay/StartReceiving) is the intended v1 scope.
New self-test "Service sender parity" asserts key + fingerprint + effective Opus frame
match the main app. Gate 26/26.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release.
Toward Ed's "every control and every function tested" goal: a new self-test applies a
profile to the ACTUAL main-window controls (via an internal ApplyThenCaptureForTest seam
on the headless form) and reads it straight back, asserting every persisted value
survived - volume, mute, send/receive toggles, peer-shaping master, send mode, send-all-
applications, and the selected applications. This exercises each control's load AND save
logic, not just that it exists (which the accessibility audit already covers).
The apply path pops the "set a password to stream" dialog when enabling send with no
password (would hang a headless test); the seam sets the existing suppressStreamingPasswordGate
around the apply, same gate the app uses internally.
Gate 25/25.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Closes the second test gap.
- RecordingController gets an internal SettingsSourceForTest seam so a self-test can drive
a split (multi-track) recording without writing to the real shared settings store.
- New self-test "Recording split tracks": with SplitTracks on + one connected peer, starts
the real controller, feeds the "your send" track through the tap it wires onto the sender,
and asserts it wrote a FOLDER of tracks (one per peer plus your own) with content - Ed's
multi-track feature, now proven on every build.
Gate 24/24. Both previously-deferred test gaps (split-track + main-window tabs) now closed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Closes the UI-coverage gap Ed pushed on.
- MainForm gets a `headless` ctor flag (defaults false → real startup path byte-for-byte
unchanged). When true it builds the WHOLE window — every tab, control and menu — but
skips the OS touches: global-hotkey registration, the status/device-refresh timers, the
device-change notifier, and the audio-backend mode switch in ApplyAsioMode. The
disruptive startup work (Connect + sockets, UPnP, update check) already lives in the
Shown handler, which never fires when a test constructs the form without showing it — so
a headless construction is naturally side-effect-free.
- New self-test "Main window coverage": constructs the headless main window and audits the
lot — accessible names present, Alt mnemonics unique per group, tab order forms no cycle.
4 tabs, 41 interactive controls.
- It immediately EARNED ITS KEEP: caught a real Alt+L collision — the WASAPI latency and
ASIO latency labels both claimed Alt+L in the same panel, so in WASAPI+ASIO mode the ASIO
field was unreachable by its shortcut. Moved ASIO latency to Alt+I; WASAPI keeps Alt+L.
Gate 23/23.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release.
- New "Recording churn / soak": rapidly start/feed/stop/dispose recordings across all
four formats, asserting handles stay bounded - catches recorder/encoder lifecycle
leaks a single recording wouldn't.
- Both the recording churn and the lifecycle churn now honour REMSOUND_TEST_SOAK=<seconds>:
unset, one quick round in the gate; set, they hammer until the deadline for a real
minutes-long soak. Verified at 8s: 312 lifecycle transitions + 16 record cycles.
- Handle checks now force GC + finalizers to settle before measuring, so the reading
reflects genuine leaks, not collection lag under fast churn (which would false-fail a
long soak). Post-settle the churn shows NEGATIVE handle growth - no leaks.
Gate 22/22.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release.
- The accessibility audit now covers 8 dialogs (was 3): Recording settings,
Preferences, Service profile, About, Add EQ band, Rename peer, Keyboard shortcut
import, Profile selection. Each is constructed and checked for accessible names on
every control + unique Alt mnemonics per group.
- Added a tab-order sanity check to the audit: the GetNextControl walk must terminate
(no cycle) for every audited form - guards a keyboard/screen-reader user from a Tab
trap, and the wrapper-TabIndex trap we've hit before.
Deferred (documented): auditing the MAIN WINDOW's tabs needs a headless construction
seam - MainForm's ctor opens audio backends, registers global hotkeys, binds sockets
and shows a tray icon, interleaved through the ctor. A `headless` flag that skips those
is safe in principle (real path unchanged) but invasive on the critical startup path
and best added with Ed able to test it. The dialog surface (most of the app's controls)
is now covered. Gate 21/21.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. First test-suite increment.
New self-test "Recording engine" drives the real AudioRecorder headless by feeding
its audio-thread taps a synthetic tone, then asserting the output files:
- every format written with real content: WAV / MP3 (LAME) / OGG-Opus (Concentus) /
FLAC (FLAKE), native encoders and all.
- source gate: a SentOnly recorder fed only received audio stays (near) empty.
- mono downmix produces a valid smaller WAV.
This is the recording pain Ed flagged - now proven on every build instead of by ear.
Follow-up: split-track (per-peer) recording is orchestrated by RecordingController,
which reads settings from the shared store; testing it without mutating real config
needs a settings-injection seam. Deferred, noted.
Gate 21/21.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release.
- ServiceProfileDialog: modal 3-tab editor (Audio send / Audio profile / Connectivity)
reusing the house controls, with a Save and Close / Cancel / Additional options
button row. Send-only: send-mode chooser + WASAPI outputs/apps + inputs (no "Send
my audio" toggle, no receive, no ASIO); codec/rate/lock-to-clock; peers add/remove +
a Set password button. Additional options sub-dialog = play connect/disconnect sound
+ enable service logging. Edits a Profile clone; returns it on OK.
- Service menu in MainForm: status line + Configure / Install / Uninstall / Start / Stop,
items enabled per live state on drop-down. Install/uninstall confirm then elevate.
Configure saves the reserved service profile, points AppConfig at it, stores the
machine-wide logging choice, and restarts a running service to pick up edits.
- ProfileStore.ReservedServiceProfileTitle ("RemSound service"): the service profile
lives with normal profiles (so the service Loads it) but ListProfileTitles hides it
from every picker. ServiceControl reuses that single constant.
- Self-test: the service dialog is now in the accessibility audit (constructs cleanly,
unique mnemonics, all controls named). Gate 20/20.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release.
- RemSoundService (ServiceBase): hosts ServiceSendHost.RunLoop on a worker thread,
OnStop cancels + joins. Added System.ServiceProcess.ServiceController package.
- ServiceControl: install (sc.exe create, auto-start, careful binPath quoting) /
uninstall (stop + delete) / start / stop / status. Status query is unprivileged
(menu can poll it); the mutating verbs self-elevate via ShellExecute runas.
- Program.cs: early guards for --run-service (blocks in the SCM dispatcher) and the
one-shot elevated verbs, before the single-instance lock (the service is a
separate role and must never take the interactive lock).
- Self-test "Service registration args" verifies the sc create binPath quoting
survives a spaced exe path. Gate 20/20.
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>
Local checkpoint - NOT for public release.
Ed's ask: the ASIO-toggle crash was a lifecycle-transition bug, and those take an
age to test by hand but regress easily. Automate tearing features down and adding
them back in every combination.
New self-test "Lifecycle churn" drives a REAL sender+receiver pair over loopback
through a matrix of runtime transitions and asserts no crash + bounded handles:
- audio mode changes
- send sources: empty / device loopback / process-loopback (own pid) / both,
reconfigured repeatedly so the process-loopback capture is torn down and rebuilt
many times (the mechanism that hard-crashed)
- receive outputs on/off
- per-peer pan + parametric EQ: none / volume-only / full pan+EQ chain
- codec (PCM/Opus) and tight-latency toggles
- a rapid WASAPI-only reconfigure loop (no mode changes, never abuses hardware)
Any unsafe teardown crashes the test process and fails the gate; it also checks
handle growth stays bounded across the churn (caught nothing leaking: +25).
Real ASIO hardware cycling is OPT-IN via REMSOUND_TEST_ASIO ("1" = first installed
driver, or a driver name) so routine builds never open - and possibly hang or lock -
a real interface. When set it adds a GENTLE ASIO on/off loop (4 toggles, 600ms settle
- some drivers stall for seconds on a quick close+reopen) with a process-loopback
source live across the toggle, i.e. the exact Ed repro. Verified on the Audient:
52 transitions, no crash.
Gate: 17/17 (default, WASAPI-only path).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release.
Repro (Ed): in applications send mode with an app being captured, turning the
ASIO driver off hard-crashed the process. No log and no crash-report file were
written - and MixingEngine.DisposeEntry swallows managed exceptions - which points
to a native access violation, not a managed throw.
Cause: the ASIO toggle rebuilds the capture backend (ApplyAsioMode -> ApplyAudioRuntime
-> ApplySendSources), which disposes the live ProcessLoopbackCapture. The old design
released the WASAPI COM objects from the disposing thread while the capture thread
could still be inside a native GetBuffer call - a classic use-after-free / AV.
Fix: the capture thread now owns the ENTIRE COM lifecycle. It activates, runs, and
releases every COM object itself, in its finally, only after the loop has exited.
StopRecording/Dispose merely signal and join (2s) - they never touch the COM objects.
If the thread ever wedges in a native call we leak it rather than free from outside
(a rare bounded leak beats a hard crash). The thread is also explicitly MTA, and
activation moved onto it, so the async-activation callback can't stall the UI thread.
bufferReady is volatile and only disposed once the thread has genuinely exited.
Also: ApplyAsioMode force-sets the WASAPI send-list visibility for the new mode, which
resurrected the loopback-outputs list in applications mode; re-assert ApplySendModeVisibility
at the end so the correct list stays shown after an ASIO toggle.
New self-test "Per-application capture lifecycle" runs real start/stop/dispose cycles
of the native capture against our own process on hardware - a bad teardown would AV
and fail the gate. Gate: 16/16.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Builds on the engine core commit.
Ed's revisions to the plan: the send-mode chooser lives on the Input/Output tab
(not Preferences), right after "Send my audio", and the setting saves per profile.
Input/Output tab:
- New "How to send WASAPI audio" listbox (Alt+6) after the send checkbox, with
two rows: send whole sound devices (classic) or send specific applications.
Switching it swaps the tab live between the loopback-outputs list and the app
section. Hidden entirely on Windows too old for process loopback (mode pinned
to devices), so nothing changes for Win7.
- Applications section: "Send all applications" master checkbox (Alt+7, ticked by
default = whole system audio, same as today) and an "Applications to send"
checked list (Alt+8) shown only when the master is unticked.
- All house controls (AccessibleCheckBox, MnemonicLabel, WireCheckedListAccessibility),
accessible names + Alt-shortcut suffixes, tab order slotted in.
Behaviour:
- App list reconciles on a 3s timer while visible: apps appear/disappear as they
open and close, ticks preserved by process NAME, and a ticked app that closes
stays in the list marked "(not running)" and resumes when it reappears.
- ApplySendSources: devices mode unchanged; applications mode sends either the
default-render loopback (send all) or one process-loopback spec per running
process of each ticked app. WASAPI mics and ASIO run alongside in both modes.
- Process-loopback sources are excluded from the single-source push-mode fast
path (it opens an MMDevice; a "proc:<pid>" id has none) - they go via MixingEngine.
- "Is anything being sent" status/tray gates account for applications mode.
Persistence moved from AppConfig to Profile: WasapiSendMode / SendAllApplications /
SelectedSendApplications. Profile round-trip self-test extended. Gate: 15/15.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release.
Fan-out (every received stream to every selected output, no added latency):
- SessionPlayout mirror replicas fed the same decoded bytes; delicate ReadFloats untouched.
- PlayoutEngine reconciles replicas per active output lane; per-route tuner
aggregation keeps lanes from disturbing each other. Recording dispatch gated
to the recording route only.
- PeerDspChain.Clone() gives each output lane independent biquad state.
- ReceiverSelfChecks.FanOutToBothOutputs proves both lanes get audio (self-test).
Offline-marker pile-up fix:
- ResolvePeerDisplayName strips the " (offline)" marker before reuse, so a ghost
peer no longer compounds the suffix hundreds of times in the status line.
Issue #19 (Use-Windows-default follower in the loopback send list):
- DefaultLoopbackSendFollower resolves to the current default render device's
loopback spec, re-applied when the default changes.
Per-application send engine core (issue #20) - WASAPI-only, Win10 19041+ gated:
- CaptureKind.ProcessLoopback + ProcessLoopbackId ("proc:<pid>").
- AudioAppEnumerator: snapshots apps with audio sessions, tracked by process
name, releasing every session object each pass so nothing piles up.
- ProcessLoopbackCapture: IWaveIn over the process-loopback activation API
(hand-rolled COM interop; NAudio has no binding). Fixed 48k/float/stereo.
- CaptureSource IWaveIn overload; MixingEngine opens "proc:<pid>" sources with
no MMDevice and no render keepalive. ASIO path untouched.
- Self-test enumerated real apps on hardware; support gate verified.
UI (Preferences device/app mode + app checklist), ApplySendSources app specs,
and the reconcile timer are still to come. Gate: 15/15.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Multi-track recording drift fix (Ed's question — can the separate tracks drift over an hour?):
* Root: FlushPeerTracks skipped a peer that produced no samples in a render block, so a peer that
went quiet long enough for its session to be pruned (>4 s idle) would have its track fall behind
and desync. Now every peer track is padded to a full render block each cycle (silence when the
peer produced nothing), so all peer tracks stay sample-locked to the single render clock — they
can't drift apart however long the recording runs, and all end the same length. Same padding for
the single-file bypass path. OnRecordBlockComplete now carries the block's float count.
(The peer tracks are already resampled to the render clock per peer, so this makes peer-to-peer
sync exact; your own "me" track is capture-clocked — same soundcard for capture+playback = same
clock = no drift, different interfaces can drift slightly.)
* Self-test: two new steps — "Per-peer shaping DSP" (PeerDspChain unity/master-off/volume/parametric
+ ParametricToPeaking) and "v5 settings and shaping round-trip" (AppConfig defaults, NamedPeers,
MainTabOrder, parametric PeerShaping, recording default = Both).
* Logging (gated by the logging checkbox): master shaping switch, EQ-mode change, parametric band
add/delete, peer rename/clear/delete, and the applied Appearance settings after Preferences close.
* CLI: --list-profiles and --list-named-peers (read-only), in --help.
* Version bumped to 5.0; About-box changelog, RELEASE_NOTES.md and README updated for v5.
Build clean; --selftest passes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace the running-version-vs-saved-version trigger for the "what's new" popup with a
one-shot marker the updater writes ONLY on a successful update (UpdateApplier success
path). A failed/rolled-back update never writes it (and clears any stale one), so it can
no longer re-trigger what's-new — the old best-effort flag save could lose a race during
the update churn and leave the version mismatched, which was the bug.
New WhatsNewMarker seam (Write/Exists/Consume) + a SelfTest case for the consume-once
contract. MaybeShowWhatsNewAfterUpdate now shows iff the marker is present, then deletes
it; still records LastWhatsNewVersion for the import-offer's upgrade detection.
Not released yet — bundling with the connection-retry (#15) work in the next release.
No version bump, no manual change (internal fix).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- New screen-reader hotkey "Speak the RemSound status information" (issue #13):
reads the status line aloud through the active screen reader via Tolk, fires from
anywhere (system-wide), unset by default. Built behind an IScreenReaderOutput seam
so a future build can swap Tolk for Prism on Windows 10+ without touching callers.
Tolk DLLs vendored under tolk/ and shipped next to the exe.
- New Logging tab in Preferences: Enable logs + Write logs now moved there, plus
opt-in startup "warn if logs folder exceeds N MB" and "delete logs older than N days",
and a "Delete all logs" button (Yes/No confirm). New LogMaintenance helper + AppConfig
settings drive it.
- Manual (readme.html + regenerated MANUAL.md), About changelog and RELEASE_NOTES
updated in plain English; csproj <Version> bumped to 4.3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Audio cues
- Cues for send/receive on-off, minimise/restore, checkbox tick/untick, and tab switch
- Soft keyboard clicks while typing, with a distinct passkey sound on password fields
- Per-cue "Choose sound" variant picker; "(none)" silences a cue; front-most missing-sound warning
- Send/receive cues take priority over the generic checkbox sound; programmatic ticks stay silent
Preferences
- Redesigned into four tabs (General, Audio cues, Startup behaviour, Update settings)
- Startup behaviour moved in from the Options menu
- NVDA now announces the dialog on open (focus a real named control, not the quiet tab control)
Auto-tune
- Cause-aware: tells device render-callback stalls (more buffer can't fix) apart from genuine
network/buffer starvation, so it no longer pins latency high on chunky onboard cards
- Lowering the target eases the buffer down (glide) instead of trimming it, so no clicks while tuning
Sounds layout
- Shipped defaults moved out of the per-user folder into an install-side "default sounds" folder,
so updates can refresh them; user customs are Browse-picked file paths and are left untouched
- Startup migration removes both legacy sound folders; verified from oldest (v1.0-v3.3) and v3.4 layouts
Quiet automated launches
- New --silent launch flag mutes all cue sounds and suppresses the startup dialogs (migration notice,
update check, Realtek/mic/missing-sound warnings) so test launches never disturb the user
- run-tests / build-release / SelfTest repointed to the new "default sounds" layout
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Preferences dialog is now a QuietTabControl with four tabs (same accessible tab approach as
the main window; Ctrl+Tab / arrows switch tabs):
- General: profiles-folder browse, accept-remote-volume, UPnP, enable logs / write logs now.
- Audio cues: the redesigned cue UI (plain cue list + "(none)" sound option) + keyboard clicks.
- Startup behaviour: Start minimised / Start with Windows / Start with a specific profile -
moved here from the standalone Options-menu dialog, wiring and persistence unchanged (AppConfig
+ the Windows auto-start registry entry).
- Update settings: startup-check, frequency, check-now, silent-install, show-what's-new.
Removed the Options-menu "Startup behaviour" item and deleted the now-unused
StartupBehaviourDialog.cs (and dropped it from the self-test's accessibility audit). The audit
still passes on the tabbed dialog with no mnemonic clashes (Alt-letters are isolated per tab).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Part 1 - "Uncheck all inputs and outputs" button now also resets the ASIO driver to "(none)":
renamed to say so, and UncheckAllDevices sets asioDriverBox to row 0 for a full clean
WASAPI-only, nothing-selected state.
Part 2 - checkbox tick/untick sounds: every checkbox toggle anywhere in RemSound now plays a
short cue (check.wav on tick, uncheck.wav on untick) - instant feedback on which way a box
went, especially in the inputs/outputs lists. New CheckSoundService + two machine-wide cues
(CheckboxOn/Off) with the usual numbered-variant + Preferences treatment. Hooked from
AccessibleCheckBox.OnCheckedChanged and the device lists' WireCheckedListAccessibility, both
gated on the control being Focused so a genuine user toggle clicks but bulk programmatic
(un)checking (profile load, "uncheck all") stays silent. Reloaded at startup and on cue change.
Tests + manual updated; .sfk byproducts cleared.
Remaining for the overhaul (next): tabbed Preferences (General / Audio cues / Startup behaviour /
Update settings), the cue-list redesign with a "none" option replacing per-cue checkboxes, moving
Startup behaviour out of the Options menu, and a front-most "missing sound file" error.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Six new machine-wide cues, each with the same numbered-variant + Preferences treatment as
the others (enable tickbox, Choose default sound picker, Play/Browse):
- Send turned on / off, Receive turned on / off: fire from OnStreamingCheckboxChanged, so
they sound whether the user clicked the in-window tickbox or pressed the mute shortcut
(the hotkey flips .Checked, which routes through the same handler). Suppressed during
profile load by the existing password-gate guard, so loading a profile doesn't blast them.
- Minimise (hide) / Restore (show): fire from the tray controller's Minimize()/Restore() on a
genuine visibility transition (guarded against no-op / startup-minimise).
Enable flags + custom-WAV overrides for these six live machine-wide in AppConfig
(EnableSendOnCue.., MachineCueCustomPaths) - they're app-level feedback, not per-profile
audio - so no Profile/settings-cache plumbing. TryLoadCueSound now also honours the
machine-wide custom path. PreferencesDialog gains a MachineRow helper + the six rows.
Sounds: shipped via the existing sounds\*.wav wildcard. Fixed an obvious typo in the
supplied files ("rcieve off 1.wav" -> "recieve off 1.wav") so receive-off has both variants.
Renamed the old single-name cue WAVs to Ed's numbered-variant set; added key/passkey and the
new cue sounds.
build-release.ps1: new step deletes the SoundForge .sfk peak-file byproducts from sounds\
before packaging (they never shipped - build is *.wav only - this just keeps the tree tidy).
Tests + manual updated for the six new cues.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cue sounds now ship as numbered variants ("connect 1.wav", "connect 2.wav", ...); the
count is never hard-coded so more can be added with no code change.
- CueSounds.cs: discovers a cue's "<base> <n>.wav" variants (case-insensitive) and
resolves the active default: per-profile custom WAV > machine-wide chosen variant >
first variant > silent. Wired into MainForm.TryLoadCueSound, the startup cue in
Program.cs, and PreferencesDialog.ResolveCueFilePath.
- AppConfig: DefaultCueSounds (machine-wide cueId -> chosen filename) and
EnableKeyboardClicks (on by default).
- Preferences: a "Choose default sound" listbox under the cue checklist - it lists the
selected cue's variants, arrowing it previews each sound and makes it that cue's
default. Plus a "Play keyboard clicks when typing into any edit field" checkbox.
- KeyClickService.cs: an app-wide WM_CHAR message filter + a low-latency NAudio mixer.
Typing into any edit field plays a random key click (key 1..N.wav); password fields
also play passkey.wav at the same instant. On/off live from the Preferences toggle.
Inert if the sounds are missing or the device won't open; never consumes the keystroke.
- csproj: ship every sounds\*.wav via a wildcard (variants, key clicks, passkey, future
additions) instead of stale per-file canonical names.
- Tests: resource checks (self-test + run-tests.ps1) now verify each cue has >=1 variant
and that key 1.wav / passkey.wav are present. Accessibility audit still green with the
new Preferences controls (Alt+D, Alt+K - no mnemonic clashes).
- Manual: variant picker, keyboard clicks, and the new sound-file naming documented.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Andre's three "bigger ideas" from RemSound-smoke-test-agent-brief.md:
- Richer diagnostics: --diagnostics now includes a live localhost audio self-check
(PCM + Opus, with packet/underrun/drop/buffer/latency counters), the most recent
session snapshot parsed from the log (codec, send/receive state, buffer, drops,
heartbeat), and a recent-warnings/errors digest from the log. BuildDiagnosticsReport
gained a runLiveAudioProbe flag so the self-test's privacy check stays fast.
- Headless accessibility audit: new --selftest step constructs the dialogs that can be
built without hardware (Startup behaviour, Recording settings, Preferences) and checks
every actionable control announces a name and that Alt-key mnemonics are unique within
a container. MainForm is out of scope (its constructor opens audio/hotkeys/sockets).
Dialogs that won't construct are skipped, not failed. Currently audits 3, no violations.
- Perf/leak sanity: new --perftest command runs several audio-loopback cycles and reports
whether handle/memory/thread counts stay bounded (handles ratcheting up cycle-on-cycle is
the leak fingerprint, given RemSound's handle-leak history). Lenient thresholds; logs the
numbers for build-to-build comparison. Wired into run-tests.ps1.
- Shared AudioLoopback helper (used by the self-test, diagnostics and perf test) so all
three exercise the identical real capture/encode/network/decode path on test port 47929.
- csproj: the four previously-unconditional cue Content items are now Exists-guarded like
the rest, so a mid-edit sounds\ folder doesn't break the dev build; the gate still
enforces the required cues before release.
Help + manual updated (--perftest, --smoke-test, --config-dir, richer --selftest).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The test suite, modelled on Andre's Sensor Readout (an in-app self-test + a build
script), runnable as one step before every publish.
Part 1 - in-app multi-step self-test (SelfTest.cs), run by --selftest:
audio round-trip (PCM + Opus over localhost, dedicated test port so it never
clashes with a running instance), encryption right/wrong-password + fingerprint,
packet framing + malformed rejection, client<->server wire-format compatibility,
settings save/reload, profile save/reload (temp folder), diagnostics-report
privacy (never leaks a password), and bundled-resources present. Each step is
timed and reported PASS/FAIL/SKIP; exit 0 only if nothing failed. Replaces the
old single-shot --selftest. RunDiagnostics refactored to expose
BuildDiagnosticsReport(AppConfig) for the privacy step.
Part 2 - run-tests.ps1: builds, then checks the package (sounds, readme, native
opus, framework-dependent, dll version == csproj), the About-box changelog, the
client/server wire contract (relay magic/version/port still match RemPacket),
the CLI surface, and runs --selftest. build-release.ps1 now runs this gate first
and aborts the release if it fails.
Bug caught + fixed: the published release zip carried ZERO cue sounds (startup
sound + connect/disconnect/etc.) - MSBuild's incremental Content-copy marker
skipped sounds\ on a fresh publish. Added an AfterTargets=Publish copy in the
csproj that lands every cue WAV in the published sounds\ folder regardless of
the marker. Verified: a staging publish now contains all 9 cue WAVs.
Manual/help: --selftest description updated (readme.html + MANUAL.md).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
EdnunpandClaude Opus 4.8