Report preparation
What happened?
What happened?
After connecting to the radio, TCI audio on DAX channel 1 does not start automatically/correctly. No audio is heard until I manually change the slice mode and then toggle DAX 1 off and back on. Simply toggling DAX 1 off/on by itself does not restore audio — only the mode-change-plus-toggle sequence works, and even then it seems to require also touching frequency in some cases.
Separately, when I launch another application that connects to AetherSDR (or the radio) over TCP — e.g. a logging program or another TCI/CAT client — the existing DAX/TCI audio stream stops working entirely.
This points to either:
The DAX/TCI audio stream not being (re)initialized correctly on the initial stream create type=remote_audio_rx / DAX subscription, with the mode change acting as a side-channel trigger that forces a status refresh, or
The audio stream binding/ownership being torn down or mis-filtered when a second TCP client connects (multi-client / client_handle filtering issue).
What did you expect?
TCI audio on DAX 1 should start working as soon as the channel is enabled, with no need to change mode or frequency first.
Connecting a second TCP client (CAT, TCI, or another companion app) should not interrupt or kill the existing DAX/TCI audio stream for AetherSDR's own connection.
Steps to reproduce
Launch AetherSDR 26.6.3 on Windows and connect to a FLEX-6400 (fw 4.2.20.41343).
Enable TCI and DAX channel 1 audio.
Observe that no audio is heard, even though DAX/TCI appears connected/enabled in the UI.
Toggle DAX 1 off, then on again — audio still does not start.
Change the slice mode (e.g. USB → LSB) and then toggle DAX 1 off/on — audio now starts working.
With audio working, launch a separate program that opens its own TCP connection to the radio (e.g. a TCI client, logger, or CAT control app).
Observe that AetherSDR's DAX/TCI audio stream stops producing audio.
Radio model & firmware
FLEX-6400, firmware 4.2.20.41343
OS & version
Windows, AetherSDR 26.6.3, Qt 6.8.3
Developer Notes
I wasn't able to inspect the actual source tree (no repo browsing access beyond CLAUDE.md), so the following is inferred from the architecture/protocol notes in CLAUDE.md rather than verified line numbers — please treat file/line references as starting points, not confirmed locations.
Likely areas to investigate:
src/core/AudioEngine (RX/TX audio + DSP pipeline) — look at how DAX channel enable/disable is wired to the underlying VITA-49 audio stream subscription. If toggling DAX only flips a UI/model flag without re-sending the corresponding stream create/audio subscribe command (or without re-binding the UDP audio stream), audio would stay silent until some other status update (like a mode change triggering a broader status refresh) incidentally re-syncs state.
src/models/RadioModel and whatever model owns DAX/TCI channel state — check the commandReady(cmd) → radio path for DAX enable. Confirm the exact command sent on DAX 1 enable matches what the radio expects (per CLAUDE.md's protocol quirks section, several "obvious" command names are wrong, e.g. audio_level vs audio_gain, client set local_ptt vs enforce_local_ptt). It's plausible there's a similarly mismatched or missing DAX subscribe/audio-stream command.
PanadapterStream (VITA-49 routing by stream ID / PCC) and the Multi-Client / Multi-Flex filtering logic described in CLAUDE.md — this is the most likely culprit for the "second TCP client breaks audio" symptom. Per the doc, VITA-49 packets are filtered by client_handle via setOwnedStreamIds(panId, wfId), and early status messages can arrive without a client_handle. If a second client's connection causes a status/handle re-broadcast that AetherSDR mis-applies (e.g. temporarily treating the DAX/audio stream as not-owned, or re-evaluating m_ownedSliceIds/stream ownership incorrectly), audio could silently stop without a UI error.
Check whether DAX audio stream setup is being treated as radio-authoritative vs client-authoritative correctly — if DAX enable state is being persisted/restored from AppSettings in a way that fights with the radio's own session state on reconnect or on a second client's status broadcast, that could also explain the symptom.
Logging to request from the user (Help → Support):
Audio / DAX-specific log category (likely under AudioEngine/DAX logging — check qCWarning/qCDebug categories tied to DAX and TCI)
Protocol/network logging category to capture raw S/C/R status and command traffic, specifically around: DAX 1 enable, the mode change that "fixes" it, and the moment the second TCP client connects
Multi-client logging, if a separate category exists, to capture client_handle assignment/changes when the second TCP connection is made
Suggested diagnostic ask for the reporter:
A Wireshark capture (or AetherSDR's built-in protocol log) covering: connect → enable DAX 1 (broken) → change mode + toggle DAX (fixed) → launch second TCP client (breaks again) would let a maintainer compare the exact stream create/audio/client_handle traffic in the broken vs. working states.
What did you expect?
TCI audio works automatically when invoked.
Steps to reproduce
In "what happen" above
AetherSDR version
26.6.3
Radio model & firmware
Flex 6400 Firmware 4.2.20
Operating system
Windows
OS version and hardware
Windows 11 25H2 Pro
Report preparation
What happened?
What happened?
After connecting to the radio, TCI audio on DAX channel 1 does not start automatically/correctly. No audio is heard until I manually change the slice mode and then toggle DAX 1 off and back on. Simply toggling DAX 1 off/on by itself does not restore audio — only the mode-change-plus-toggle sequence works, and even then it seems to require also touching frequency in some cases.
Separately, when I launch another application that connects to AetherSDR (or the radio) over TCP — e.g. a logging program or another TCI/CAT client — the existing DAX/TCI audio stream stops working entirely.
This points to either:
The DAX/TCI audio stream not being (re)initialized correctly on the initial stream create type=remote_audio_rx / DAX subscription, with the mode change acting as a side-channel trigger that forces a status refresh, or
The audio stream binding/ownership being torn down or mis-filtered when a second TCP client connects (multi-client / client_handle filtering issue).
What did you expect?
TCI audio on DAX 1 should start working as soon as the channel is enabled, with no need to change mode or frequency first.
Connecting a second TCP client (CAT, TCI, or another companion app) should not interrupt or kill the existing DAX/TCI audio stream for AetherSDR's own connection.
Steps to reproduce
Launch AetherSDR 26.6.3 on Windows and connect to a FLEX-6400 (fw 4.2.20.41343).
Enable TCI and DAX channel 1 audio.
Observe that no audio is heard, even though DAX/TCI appears connected/enabled in the UI.
Toggle DAX 1 off, then on again — audio still does not start.
Change the slice mode (e.g. USB → LSB) and then toggle DAX 1 off/on — audio now starts working.
With audio working, launch a separate program that opens its own TCP connection to the radio (e.g. a TCI client, logger, or CAT control app).
Observe that AetherSDR's DAX/TCI audio stream stops producing audio.
Radio model & firmware
FLEX-6400, firmware 4.2.20.41343
OS & version
Windows, AetherSDR 26.6.3, Qt 6.8.3
Developer Notes
I wasn't able to inspect the actual source tree (no repo browsing access beyond CLAUDE.md), so the following is inferred from the architecture/protocol notes in CLAUDE.md rather than verified line numbers — please treat file/line references as starting points, not confirmed locations.
Likely areas to investigate:
src/core/AudioEngine (RX/TX audio + DSP pipeline) — look at how DAX channel enable/disable is wired to the underlying VITA-49 audio stream subscription. If toggling DAX only flips a UI/model flag without re-sending the corresponding stream create/audio subscribe command (or without re-binding the UDP audio stream), audio would stay silent until some other status update (like a mode change triggering a broader status refresh) incidentally re-syncs state.
src/models/RadioModel and whatever model owns DAX/TCI channel state — check the commandReady(cmd) → radio path for DAX enable. Confirm the exact command sent on DAX 1 enable matches what the radio expects (per CLAUDE.md's protocol quirks section, several "obvious" command names are wrong, e.g. audio_level vs audio_gain, client set local_ptt vs enforce_local_ptt). It's plausible there's a similarly mismatched or missing DAX subscribe/audio-stream command.
PanadapterStream (VITA-49 routing by stream ID / PCC) and the Multi-Client / Multi-Flex filtering logic described in CLAUDE.md — this is the most likely culprit for the "second TCP client breaks audio" symptom. Per the doc, VITA-49 packets are filtered by client_handle via setOwnedStreamIds(panId, wfId), and early status messages can arrive without a client_handle. If a second client's connection causes a status/handle re-broadcast that AetherSDR mis-applies (e.g. temporarily treating the DAX/audio stream as not-owned, or re-evaluating m_ownedSliceIds/stream ownership incorrectly), audio could silently stop without a UI error.
Check whether DAX audio stream setup is being treated as radio-authoritative vs client-authoritative correctly — if DAX enable state is being persisted/restored from AppSettings in a way that fights with the radio's own session state on reconnect or on a second client's status broadcast, that could also explain the symptom.
Logging to request from the user (Help → Support):
Audio / DAX-specific log category (likely under AudioEngine/DAX logging — check qCWarning/qCDebug categories tied to DAX and TCI)
Protocol/network logging category to capture raw S/C/R status and command traffic, specifically around: DAX 1 enable, the mode change that "fixes" it, and the moment the second TCP client connects
Multi-client logging, if a separate category exists, to capture client_handle assignment/changes when the second TCP connection is made
Suggested diagnostic ask for the reporter:
A Wireshark capture (or AetherSDR's built-in protocol log) covering: connect → enable DAX 1 (broken) → change mode + toggle DAX (fixed) → launch second TCP client (breaks again) would let a maintainer compare the exact stream create/audio/client_handle traffic in the broken vs. working states.
What did you expect?
TCI audio works automatically when invoked.
Steps to reproduce
In "what happen" above
AetherSDR version
26.6.3
Radio model & firmware
Flex 6400 Firmware 4.2.20
Operating system
Windows
OS version and hardware
Windows 11 25H2 Pro