Fix silent audio in SSB/Digital modes when m_radeMode is active (#1875)#1879
Conversation
The m_radeMode guard in feedAudioData's final else-if branch silenced all non-NR audio when RADE mode was active (or stale from a previous session). CW appeared unaffected because users typically have client-side NR enabled for CW, which takes an earlier branch that bypasses the m_radeMode check. The guard is unnecessary: RADE's raw OFDM noise is already muted at the slice level (audio_mute=1) so it never reaches feedAudioData, and decoded RADE speech uses the separate feedDecodedSpeech() path. Remove the guard so the final else branch unconditionally writes audio. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ten9876
left a comment
There was a problem hiding this comment.
Defensible as code cleanup independent of the reporter's specific issue. The !m_radeMode gate is inconsistent with its own comment ('m_radeMode no longer blocks feedAudioData globally') and causes a latent multi-slice bug: when RADE is active on slice A, the old code silently drops audio from other unmuted slices even though they should play normally (RADE slice is muted server-side via audio_mute=1, not via this client-side gate).
Zero behavior change for users without RADE active (m_radeMode=false → !m_radeMode was true → writeAudio runs → same as new unconditional writeAudio). Verified by Jeremy (Linux laptop) and wa2n-code (Windows 11 LAN) — neither could reproduce rnash2's symptom. May or may not fix rnash2's specific issue, but is correct regardless.
Summary
Fixes #1875
What was changed
Fix silent audio in SSB/Digital modes when m_radeMode is active (#1875)
Files modified
src/core/AudioEngine.cppGenerated by AetherClaude (automated agent for AetherSDR)