Follow-up to #3363 — same DAX-stream-state-goes-stale class of fault as #3270 / #3363, but triggered by slice audio_mute toggle instead of a DAX bridge stop.

Honest caveat first

The sandbox I'm triaging from blocked the curl to download support-bundle-20260602-150657.zip, so I can't show packet-level evidence the way I did on #3363. The analysis below is from the source path you described in your #3363 comment ("muted from the slice flag by right clicking the speaker icon... when I reconnect TCI there is no RX signal") plus static reading of the TCI / DAX / mute code. The bundle will let a human confirm — please don't act on this without that confirmation.

What the slice-flag right-click mute does

src/gui/VfoWidget.cpp:797-802 wires right-click on the speaker tab to m_slice->setAudioMute(!m_slice->audioMute()). That calls SliceModel::setAudioMute() at src/models/SliceModel.cpp:484-490, which sends a single command to the radio:

sendCommand(QString("slice set %1 audio_mute=%2").arg(m_id).arg(mute ? 1 : 0));

Per FlexLib reference (Slice.cs:760-772, Slice.cs:2233-2249) audio_mute is purely a slice-local audio-output flag; it's documented as not touching dax_rx streams. The AetherSDR-side handler at SliceModel.cpp:655-668 only flips m_audioMute and emits audioMuteChanged. No code in TciServer.cpp or the DAX bridge listens for audioMuteChanged (verified by grep across src/), and nothing in the slice-mute path issues a stream remove or unregisters a DAX stream.

So on a clean reading the mute toggle should be invisible to TCI's DAX path. That it isn't, for you, means one of:

The radio firmware (4.2.18.41174 — saw in No tci audio again and no dax audio #3363's bundle) is dropping the slice as a DAX client on audio_mute=1 and not auto-restoring it on audio_mute=0. This would be a firmware quirk that AetherSDR doesn't currently defend against.
A second consumer (DAX bridge / RADE) is being indirectly stopped by the mute event chain and tearing the shared dax_rx stream out from under TCI — same shape as No tci audio again and no dax audio #3363's stopDax() root cause, just triggered by a different control. The "mute-all-slices" path at src/gui/MainWindow.cpp:12015-12041 is one candidate to scrutinize against your bundle's timeline.
Both — possible if RADE was active on the muted slice (MainWindow.cpp:16113-16114 force-mutes the RADE slice on activation, so the inverse on deactivate could interact).

The bundle's aethersdr.log around the mute timestamp will say which one — look for either stream remove/DAX stream removed lines for the channel TCI was using, or for dax_clients going to 0 in the radio's slice status without an accompanying stream remove.

Why "cycle the TCI control" fixes it

Toggling the Enable button on the TCI applet calls TciServer::stop() (src/core/TciServer.cpp:290-313) → releaseDaxForTci() (TciServer.cpp:1937-1969) → clears all stream IDs → start() → WSJT-X reconnects and sends audio_start → ensureDaxForTci() (TciServer.cpp:1861-1935) → recreates the dax_rx stream and re-asserts slice set <id> dax=<ch> (the #1439 workaround). Same recovery path the client-side retry triggered in your #3363 capture.

Proposed fix

Three layers — these are the same fixes I'd want for the defence-in-depth follow-up to #3363:

Reactive teardown handling (src/core/TciServer.cpp) — PanadapterStream already knows when a DAX stream is unregistered. Have TciServer connect to a daxStreamUnregistered(channel) signal (or equivalent — may need to be added) and, if that channel is in m_tciDaxStreamIds, call ensureDaxForTci() immediately to recreate it. Closes the silent gap regardless of which peer tore down the stream, and is the same shape I proposed as "Defence in depth" on No tci audio again and no dax audio #3363.
Re-arm on unmute (src/core/TciServer.cpp + slice wiring) — hook SliceModel::audioMuteChanged for every slice TCI has a DAX assignment on. On the true → false (unmute) transition, re-send slice set <id> dax=<ch> to force the radio to re-register the DAX client (the same trick ensureDaxForTci() already uses at TciServer.cpp:1924-1934 for Broken TCI audio tested on Win11 #1439). Cheap and defends against the firmware-quirk hypothesis.
Long term — Centralize DAX RX stream ownership/refcounting in PanadapterStream (multi-slice DAX/TCI hardening) #3305's centralized refcounting in PanadapterStream subsumes all of these per-path patches; everything above is "until Centralize DAX RX stream ownership/refcounting in PanadapterStream (multi-slice DAX/TCI hardening) #3305 lands."

Tactical (1) alone should make the symptom unreproducible regardless of which root cause is correct. (2) is belt-and-suspenders, particularly if it's firmware-quirk shaped.

In the meantime, for you

If you find TCI silent after a mute/unmute, you don't have to cycle the TCI Enable button — restarting WSJT-X (or its TCI connection) will send a fresh audio_start: which triggers the same ensureDaxForTci() recovery and is less disruptive than fully bouncing the server.

— AetherClaude (triage)

_{🤖 aethersdr-agent · cost: $20.4891 · model: claude-opus-4-7}

_{📍 Citation health check (Foundry Constitution Principle I): 6 resolved, 5 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (5)

Citation	Reason
`MainWindow.cpp:16113-16114`	file not found in workspace
`SliceModel.cpp:655-668`	file not found in workspace
`TciServer.cpp:1861-1935`	file not found in workspace
`TciServer.cpp:1924-1934`	file not found in workspace
`TciServer.cpp:1937-1969`	file not found in workspace

Uh oh!

TCI audio issue #3364

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions