Request preparation
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:
- 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.
- 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.
- 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
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.
Request preparation
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 toggleSummary
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:
QAudioSink) → radio hardware audio output disabled → headset/keyer workflow brokenThere is no configuration that allows both simultaneously.
Root Cause
Looking at the data flow in
AudioEngine, the VITA-49 float32 audio stream (PCC0x03E3) is currently processed as a single pipeline: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:
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.QAudioSink— it should have no effect on the CW decoder's audio input.Concretely, in
AudioEngine, the CW decoder tap should be moved to run unconditionally on the incoming audio buffer, before or independently of theQAudioSinkoutput gate.Expected Behavior
Current Behavior
Implementation Notes (for contributors)
AudioEngine— moving or duplicating theCwDecoder.feedAudio()call so it runs unconditionally on the incoming float32 buffer rather than inside a PC-audio-gated branch.CwDecoderare at the correct sample rate (24 kHz) regardless of any resampling done forQAudioSink.Acceptance Criteria
Labels:
bug,audio,CWNote: This affects all CW operators using radio hardware audio — which is the recommended configuration for low-latency CW operation on FlexRadio hardware.