Repro (Windows 11)

1. Run AetherSDR (current main/PR-equivalent build) on Windows.
2. Tune to a live signal you can hear locally (e.g. 40 m LSB).
3. Start WSJT-X with TCI configured to AetherSDR (127.0.0.1:40001 etc.) — it issues audio_start:0; and force-asserts modulation:0,digu.
4. Quit WSJT-X.

Result: mode reverts (LSB), but AetherSDR's local audio output is garbled until the AetherSDR process is restarted.

What does / doesn't recover the audio

• Mode flip (LSB → USB → LSB): no effect
• Band change: no effect
• Mute toggle / volume / device switch: not exhaustively tried but in-process workarounds don't fix it
• Process restart of AetherSDR: clears it cleanly every time

Cross-platform

• Windows 11: reproduces every time
• macOS Darwin 25 arm64 (Mac mini, brew Qt6): tested with the same WSJT-X (run on a remote Windows host pointed at the Mac AE's TCI) and the Mac's local audio output remained clean — does NOT reproduce

Suspected area

The teardown lands in TciServer::releaseDaxForTci() (src/core/TciServer.cpp:1628) when the last TCI audio subscriber disconnects (:359, :466). It sends two radio-side commands per affected slice — stream remove 0x... and slice set <id> dax=0 — and clears per-client resamplers. The slice's main audio routing shouldn't be impacted by these, but on Windows the local audio sink doesn't recover. The macOS-clean result points at a Qt6 Windows audio backend (WASAPI) sensitivity to the renegotiation rather than the cross-platform TCI/audio C++ logic itself. Prior fragility in this same function: #2385 (null-deref crash). DAX bridge was NOT in play during the repro — purely TCI-internal audio path.

Workaround

Restart AetherSDR.