Skip to content

Bug / Feature Request: CW Decoder Should Not Require PC Audio to be Enabled #617

Description

@rnash2

Request preparation

  • I used an AI assistant to help structure this request
  • I checked for existing issues covering the same feature

What would you like?

Bug / Feature Request: CW Decoder Should Not Require PC Audio to be Enabled

Area: Audio / CW Decoder — AudioEngine, CwDecoder, PC audio toggle


Summary

The CW decoder currently requires PC Audio to be enabled in order to receive audio samples. However, enabling PC Audio disables the radio's own hardware audio output (headset/speaker connected directly to the FLEX-8600). This creates a mutually exclusive situation: a CW operator cannot use the radio's hardware audio output and the CW decoder at the same time.

This should be treated as a bug — the CW decoder's audio feed is an internal signal processing tap and should not be coupled to the user-facing audio output routing decision.


Problem / Use Case

CW operators using a FLEX-8600 are advised to use the radio's hardware audio outputs (headset/speaker/microphone/keyer connected directly to the radio) rather than PC audio, specifically to avoid the latency introduced by the PC audio processing chain. This is well-established practice in the FlexRadio community.

With the current AetherSDR implementation:

  • PC Audio OFF → audio goes to radio hardware output (correct for CW operating) → CW decoder receives no audio → CW decoder non-functional
  • PC Audio ON → audio routed to PC (QAudioSink) → radio hardware audio output disabled → headset/keyer workflow broken

There is no configuration that allows both simultaneously.


Root Cause

Looking at the data flow in AudioEngine, the VITA-49 float32 audio stream (PCC 0x03E3) is currently processed as a single pipeline:

VITA-49 audio → AudioEngine.feedAudioData()
                 ├── NR2 → SpectralNR.process()
                 ├── RN2 → RNNoiseFilter.process()
                 ├── CW  → CwDecoder.feedAudio()   ← should always run
                 └── → QAudioSink (PC speakers)    ← only when PC audio ON

The CW decoder tap (CwDecoder.feedAudio()) appears to be downstream of — or gated by — the PC audio output path, rather than being an unconditional tap on the incoming VITA-49 audio data. The decoder should be fed regardless of where the final audio output is routed.


Proposed Fix

Decouple the CW decoder feed from the PC audio output toggle:

  1. Always feed CwDecoder.feedAudio() from the incoming VITA-49 audio stream (after NR2/RN2 processing if applicable), regardless of whether PC audio output is enabled or disabled.
  2. The PC audio toggle should only control whether decoded audio is sent to QAudioSink — it should have no effect on the CW decoder's audio input.
  3. The CW decoder's auto-show behavior in CW mode should continue to work unchanged.

Concretely, in AudioEngine, the CW decoder tap should be moved to run unconditionally on the incoming audio buffer, before or independently of the QAudioSink output gate.


Expected Behavior

  • CW decoder functions in all audio routing configurations: PC audio ON, PC audio OFF, or DAX mode.
  • Operators using radio hardware audio (headset plugged into FLEX-8600) can use the CW decoder without any change to their audio setup.
  • PC audio toggle exclusively controls audio output destination — it has no side effect on signal processing features.

Current Behavior

  • CW decoder only functions when PC audio is enabled.
  • Enabling PC audio disables radio hardware audio output, breaking the standard CW operating setup.

Implementation Notes (for contributors)

  • The fix is likely a small change in AudioEngine — moving or duplicating the CwDecoder.feedAudio() call so it runs unconditionally on the incoming float32 buffer rather than inside a PC-audio-gated branch.
  • Care should be taken to ensure the audio samples fed to CwDecoder are at the correct sample rate (24 kHz) regardless of any resampling done for QAudioSink.
  • NR2/RN2 processing: consider whether the CW decoder should receive the raw or noise-reduced audio. Feeding noise-reduced audio is likely preferable for decode quality, but this should remain consistent with the current behavior when PC audio is ON.
  • No protocol changes required — this is entirely client-side audio routing logic.
  • The fix should be verified with PC audio OFF, PC audio ON, and DAX mode all producing a working CW decode.

Acceptance Criteria

  • CW decoder receives audio and decodes Morse regardless of PC audio toggle state
  • PC audio toggle has no effect on CW decoder functionality
  • Radio hardware audio output (PC audio OFF) works simultaneously with CW decoder
  • DAX audio mode works simultaneously with CW decoder
  • CW auto-show behavior in CW mode unchanged
  • No regression in NR2/RN2 noise reduction pipeline

Labels: bug, audio, CW
Note: This affects all CW operators using radio hardware audio — which is the recommended configuration for low-latency CW operation on FlexRadio hardware.

Metadata

Metadata

Assignees

Labels

CWCW keying, decode, and operationaudioAudio engine and streamingenhancementImprovement to existing featuremaintainer-reviewRequires maintainer review before any action is takenupstreamRequires upstream firmware/protocol changewontfixThis will not be worked on

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions