support-bundle-20260422-142100

Title: No audio output when using DAX or TCI despite active signal/audio meters (FLEX-8600, macOS)

What happened?

When using AetherSDR with a FlexRadio FLEX-8600 on macOS, audio is not heard from the Mac speakers even though the system indicates that audio is being received and processed.

Specifically:

• Slice A is active and receiving signal (visible on S-meter and waterfall).

• DAX Audio is enabled for Slice A.

• The DAX 1 audio level meter shows activity, indicating audio is being streamed from the radio.

• AetherSDR audio settings:

  • Input: AetherSDR DAX 1
  • Output: Mac Pro Speakers

• macOS system sound settings:

  • Input: AetherSDR DAX 1
  • Output: Mac Pro Speakers

Despite this:

• No audible audio is produced from the Mac speakers.

• The issue persists when switching to TCI:

  • TCI port changed to 40001
  • Connection indicator shows 1 active connection
  • Audio meter shows activity
  • Still no sound output

This suggests that audio data is successfully received and decoded (meters active), but is not being routed or rendered to the system audio output.

What did you expect?

Audio from the active slice (Slice A) should be heard through the selected macOS output device (Mac Pro Speakers) when:

• DAX audio stream shows activity, or
• A TCI audio connection is active and receiving signal

In other words, when audio meters are active in AetherSDR, corresponding audible output should be present.

Steps to reproduce

1. Launch AetherSDR (v0.8.20) on macOS.

2. Connect to FLEX-8600 radio (fw 4.1.5.39794).

3. Open Slice A and tune to an active signal.

4. Enable DAX audio for Slice A (assign to DAX 1).

5. Confirm DAX 1 audio meter shows activity.

6. In AetherSDR:

   • Set Audio Input to AetherSDR DAX 1
   • Set Audio Output to Mac Pro Speakers

7. In macOS Sound Settings:

   • Input: AetherSDR DAX 1
   • Output: Mac Pro Speakers

8. Observe: no audio from speakers.

9. Switch to TCI mode:

   • Set TCI port to 40001
   • Confirm connection established (1 client)
   • Observe audio level activity

10. Observe: still no audio output.

Radio model & firmware

• FLEX-8600
• Firmware: 4.1.5.39794

OS & version

• macOS (Apple Silicon / MacBook Pro environment)
  macOS 26.3.1 (a) (25D771280a)
  M1 Max 64 GB Memory

Developer Notes

Based on the AetherSDR architecture (per CLAUDE.md), this issue likely occurs after successful network/audio stream ingestion but before or during audio output rendering.

Likely areas of interest

Audio pipeline (DAX path):

• src/audio/DaxAudioStream.*
• src/audio/AudioEngine.*
• src/audio/AudioOutput.*

TCI audio path:

• src/tci/TciClient.*
• src/audio/TciAudioStream.*

Qt audio backend:

• QAudioSink / QAudioOutput usage (Qt 6.11.0)
• Device enumeration and format negotiation

Key hypotheses / potential root causes

1. Audio device format mismatch (very likely)

   • DAX/TCI streams may be delivering audio in a format (e.g., 24-bit, float, or non-48kHz) not accepted by macOS output device.
   • Qt6 QAudioSink can silently fail if format negotiation is invalid.
   • Symptom matches: meters active but no audible output.

2. Audio routing disconnect between input stream and output sink

   • Audio buffers may not be correctly forwarded from DAX/TCI stream handlers into the playback engine.

   • Possible missing signal/slot connection between:

     • stream decoder → audio mixer → output device

3. Muted or zero-gain stage in audio chain

   • Internal gain or volume stage may default to 0.

   • Check:

     • per-slice audio gain
     • master output gain
     • any DSP/mixer stage

4. Incorrect device selection / Qt device mapping issue (macOS)

   • “Mac Pro Speakers” may not map correctly via Qt audio device API.
   • macOS aggregate/virtual devices (e.g., DAX) can confuse enumeration.

5. TCI audio decode path incomplete or not connected to output

   • TCI connection shows activity but may not route audio to playback engine.
   • Possible missing handler in TciClient for PCM stream forwarding.

6. Threading / buffer starvation issue

   • Audio thread may not be feeding QAudioSink properly.
   • Would produce “active meters, no sound” if buffers never written.

Suggested logging (Help → Support)

Enable the following categories:

• audio.*
• dax.*
• tci.*
• network.*
• qt.audio

Look for:

• Audio format negotiation logs (sample rate, channels, sample size)

• QAudioSink state transitions (Active, Idle, Stopped)

• Buffer write confirmations / underruns

• Device enumeration output

• Errors such as:

  • “unsupported format”
  • “failed to start audio output”
  • “no bytes written”

Additional debugging suggestions

• Log selected QAudioDevice name and supported formats at runtime.

• Force test output:

  • Generate a tone locally and send directly to AudioOutput (bypassing DAX/TCI).
  • If tone is silent → output issue
  • If tone works → input routing issue

• Test with:

  • Different macOS output device (e.g., headphones vs speakers)
  • Different sample rate (48kHz vs 44.1kHz)

Summary

The issue appears to be a playback-stage failure rather than a signal acquisition issue. Both DAX and TCI paths show valid audio activity, strongly suggesting the problem lies in audio format handling, device initialization, or routing within the Qt audio output layer.