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?

What happened

TCI audio output (used by digital mode applications to receive decoded audio
from the radio) stopped working on Windows 11 starting with v0.8.12. The issue
affects all three major weak-signal / digital-mode clients tested:

• WSJTX
• JTDX
• MSHV

In all three cases the applications either see no audio device, fail to open the
TCI audio stream, or receive silence. The radio connects and the waterfall
displays correctly — the problem is isolated to TCI audio delivery.

What I expected

TCI audio should behave identically to v0.8.11: digital-mode applications should
be able to open the TCI virtual audio device and receive decoded RX audio from
the radio for decoding (FT8, FT4, JT65, MSK144, etc.).

Steps to reproduce

1. Install AetherSDR v0.8.15 on Windows 11.
2. Connect to a FlexRadio transceiver.
3. Launch WSJTX (or JTDX or MSHV).
4. In the application's audio settings, select the AetherSDR TCI audio device.
5. Observe: no audio is received / device is unavailable / decodes stop.

Confirmed last working version: v0.8.11
Confirmed broken versions: v0.8.12, v0.8.13, v0.8.14, v0.8.15 (bisect
range unconfirmed — reporter tested 0.8.11 working vs 0.8.15 broken).

Environment

• OS: Windows 11
• AetherSDR versions tested: v0.8.11 (working), v0.8.15 (broken)
• Applications affected: WSJTX, JTDX, MSHV
• Radio model / firmware: not specified — please add your model and firmware
  version in a comment

Suggested fix

Since v0.8.11 was the last known-good version, a git bisect between those two
tags should isolate the regressing commit. Likely suspects:

• Changes to the Windows virtual audio bridge (VirtualAudioBridge or the
  Windows-side DAX layer) — any refactor of the shared-memory or named-pipe
  audio path between AetherSDR and client applications.
• Changes to the TCI server component (if separate from DAX) — socket binding,
  port, or audio format negotiation.
• Sample-rate or buffer-size changes in AudioEngine that broke the negotiation
  with WSJTX/JTDX/MSHV (these apps expect specific rates, commonly 48 kHz or
  12 kHz mono).
• A Windows-specific audio device registration change (device name, GUID, or
  driver interface) that causes the virtual device to no longer appear in
  application device enumerations.

If a full bisect is not immediately feasible, diffing the AudioEngine,
VirtualAudioBridge, and any TCI-related source files between the v0.8.11 and
v0.8.15 tags is the recommended first step.

Workaround

Downgrade to v0.8.11 until fixed.

What did you expect?

No response

Steps to reproduce

No response

Radio model & firmware

No response

Linux distro & Qt version

No response