Unable to turn off PC Audio Button with IC-705

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

Title: Unable to turn off PC Audio Button with IC-705
What happened?

When I press the PC Audio button, it does not turn off. It stays green.

⚠️ Radio model discrepancy: AetherSDR is documented as a client for FlexRadio transceivers (FLEX-6000/8000/Aurora series) using the SmartSDR TCP/VITA-49 protocol. It does not support Icom radios, including the IC-705, which uses CI-V/USB audio rather than SmartSDR. If this report is against a FLEX model, please correct the "Radio model" field below before submitting.

What did you expect?

For it to turn off.

Steps to reproduce
Connect to IC-705.
Press PC Audio Button.
Observe the button remains lit green instead of toggling off.
Radio model & firmware
Radio: IC-705
Firmware: (not specified)
OS & version
AetherSDR version: 26.8.2
Qt version: 6.8.3
OS: macOS
Developer Notes

Caveat: I only had access to the project's CLAUDE.md architecture doc, not the actual source tree, so I can't cite real line numbers — the pointers below are architectural guesses based on that doc's description of the audio/settings subsystem, not confirmed code locations. A maintainer should verify against the current source.

Likely areas involved:

src/core/AudioEngine — owns RX/TX audio routing and the PC Audio source; the button state is probably bound to a member here.
MainWindow signal wiring (src/gui/MainWindow) — per the architecture doc, control widgets emit commandReady(cmd) toward RadioModel, and radio status pushes come back through applyStatus(kvs) to update the model, which then updates the widget. A stuck-on toggle is consistent with a break in that round trip.
AppSettings (src/core/AppSettings.h) — per the doc's "Radio-Authoritative Settings Policy," client-side persistence must never fight radio-side state. If PC Audio's enabled/disabled state is being persisted client-side when it should be purely radio-authoritative (or vice versa), the widget could be re-asserting a stale "on" value on every sync.

Two architecturally plausible root causes:

Missing status echo (optimistic-update problem). The doc explicitly calls out that some radio commands don't echo status back, requiring an optimistic local update — and instructs contributors to file a protocol/upstream issue whenever one is found missing. If disabling PC Audio is one of these unacknowledged commands, the button may be set optimistically off, then immediately reverted to "on" by a stray/late status message, or never actually reflect the real state if the radio never confirms it.
Feedback-loop / guard issue. The doc describes a m_updatingFromModel guard (or QSignalBlocker) pattern used specifically to prevent model-update echoes from re-triggering the UI control's own change handler. If that guard is missing or misapplied for the PC Audio button specifically, a radio status update could be immediately re-sent as a user command, effectively latching the button back on right after you turn it off.

Diagnostics to request/capture (Help → Support):

Enable the audio-related and protocol/status logging categories (exact category names weren't available from the doc — likely something like an audio and a protocol/status category following the lcCategory naming convention noted in the coding guide; check the categories listed under Help → Support → Logging in-app).
A Wireshark/pcap capture of the TCP control session around the button press would directly show whether the radio ever sends a status update in response to the PC Audio off command, which would confirm/rule out root cause #1.
Client-side log lines immediately following the button press, to see whether a command is sent and whether a subsequent status update triggers an unexpected re-send.

What did you expect?

No response

Steps to reproduce

1. Connect to Radio.
2. Press PC Audio button

AetherSDR version

v26.8.2

Radio model & firmware

Icom-705

Operating system

macOS

OS version and hardware

Macos 13.7.8

First verify the report against a supported FlexRadio model, since the issue names an Icom IC-705, which the report says is unsupported. If it reproduces, inspect the actual AudioEngine, MainWindow, and AppSettings paths rather than the unverified locations suggested in the body, then collect protocol and client logs around the PC Audio toggle. Done means the supported hardware and exact state transition are confirmed with evidence.