Conversation
v0.9.5's DAX2 coexistence policy (#2271) regressed TCI digital TX (WSJT-X / JTDX / MSHV) on Windows and Linux without PipeWire. The radio was told dax=1 but evaluateDaxTxPolicy() denied dax_tx stream creation for TciTxAudio on those platforms, so the modulator stayed silent during TX. The conceptual mistake was conflating SmartSDR DAX2's ownership of Windows DAX audio devices with the radio's dax_tx stream slot. TCI feeds its dax_tx packets from a WebSocket — it doesn't touch local audio devices and doesn't conflict with SmartSDR DAX2 at all. evaluateDaxTxPolicy() now always allows DaxTxRequestReason::TciTxAudio regardless of platform / hosted-DAX availability. Test assertions in radio_status_ownership_test.cpp flipped to match (the prior "Windows external-DAX2 TCI policy does not create dax_tx" assertion codified the regression) plus a new Linux-non-PipeWire case. macOS and Linux + PipeWire were unaffected — they hit the `tciDaxTxSupported = true` branch and were already allowed. Fixes #2276. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
ten9876
added a commit
that referenced
this pull request
May 2, 2026
The v0.9.5.1 entry was originally cut for just the TCI TX hotfix (#2285), but six additional fixes had already landed in main between the v0.9.5 tag and v0.9.5.1: - #2275 NR2 wisdom generation off the audio thread - #2278 SmartLink disconnect teardown - #2279 Reset RX slice tabs on disconnect (#2254) - #2280 macOS panadapter pop-out refresh + multi-pan dock layout - #2282 SmartLink reconnect after WAN drop - #2284 Qt log handler serialization fixes macOS tune-time crash CHANGELOG.md gets a per-fix entry with root cause + behavior change. WhatsNewData.cpp regenerated via scripts/gen_whatsnew.py so the in-app What's New dialog reflects the full v0.9.5.1 contents. Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
v0.9.5's DAX2 coexistence policy (#2271) regressed TCI digital TX
(WSJT-X / JTDX / MSHV) on Windows and Linux without PipeWire. The
radio was told dax=1 but evaluateDaxTxPolicy() denied dax_tx stream
creation for TciTxAudio on those platforms, so the modulator stayed
silent during TX.
The conceptual mistake was conflating SmartSDR DAX2's ownership of
Windows DAX audio devices with the radio's dax_tx stream slot. TCI
feeds its dax_tx packets from a WebSocket — it doesn't touch local
audio devices and doesn't conflict with SmartSDR DAX2 at all.
evaluateDaxTxPolicy() now always allows DaxTxRequestReason::TciTxAudio
regardless of platform / hosted-DAX availability. Test assertions in
radio_status_ownership_test.cpp flipped to match (the prior
"Windows external-DAX2 TCI policy does not create dax_tx" assertion
codified the regression) plus a new Linux-non-PipeWire case.
macOS and Linux + PipeWire were unaffected — they hit the
tciDaxTxSupported = truebranch and were already allowed.Fixes #2276.
Co-Authored-By: Claude Opus 4.7 (1M context) [email protected]