Summary

Fixes #2207 — RADE digital voice mode is absent from the official Windows installer because both the installer workflow and the Windows CI job were explicitly passing -DENABLE_RADE=OFF at CMake configure time. Local builds work because ENABLE_RADE defaults to ON in CMakeLists.txt; only CI-produced artifacts were silently missing the feature.

Root Cause

Both workflow files opted out of RADE:

# windows-installer.yml line 47 (before this PR)
cmake -B build -G "Ninja" -DCMAKE_BUILD_TYPE=Release -DENABLE_RADE=OFF -DMQTT_TLS=OFF

# ci.yml line 131 (before this PR)
"-DENABLE_RADE=OFF",

This is a packaging decision, not a source-code limitation. The build infrastructure to support RADE on Windows already exists and is correct:

• third_party/radae/cmake/BuildOpus.cmake has a complete WIN32 branch that builds a RADE-capable static Opus (-DOPUS_DRED=ON -DOPUS_OSCE=ON) via CMake ExternalProject
• third_party/opus-rade/opus-rade-prepared.tar.gz is vendored in the repository
• The Linux AppImage workflow (appimage.yml) already ships with RADE enabled and uses an identical Build Opus step pattern
• @wa2n-code's local MSVC build (reported in RADE not availble on Windows 11 unless compiled from source locally #2207) confirms the Windows path works end-to-end

Changes

Two workflow files, no source changes:

Why a Separate build_opus Step?

BuildOpus.cmake correctly declares BUILD_BYPRODUCTS and add_dependencies(opus build_opus), so the Ninja dependency graph would handle ordering automatically. The explicit step is kept for two defensive reasons (matching the AppImage workflow's established pattern):

1. CI failure attribution — if the Opus ExternalProject fails, the step name makes the problem immediately obvious rather than surfacing as a cryptic link error inside the main Build step
2. Ninja/ExternalProject ordering — ExternalProject + IMPORTED targets + Ninja have a history of parallel-build ordering edge cases across CMake versions; the explicit step eliminates that class of flakiness entirely with no downside

Packaging Impact

• RADE Opus is BUILD_SHARED_LIBS=OFF → statically linked into AetherSDR.exe
• No new DLLs to add to the deploy step or Inno Setup script
• Neural-net weights are compiled in via rade_enc_data.c / rade_dec_data.c — no external model files to bundle
• setup-opus.ps1 (generic Opus for SmartLink compressed audio) remains in place; when RADE_FOUND=TRUE, CMakeLists.txt routes all Opus linkage through the vendored RADE build, so the prebuilt generic Opus is unused but harmless
• AetherSDR.exe will be larger (~8–12 MB, matching the AppImage delta) due to compiled-in weights

Known CI Impact

CMAKE_C_COMPILER_LAUNCHER=sccache is not forwarded into the ExternalProject subprocess, so the Opus build will not benefit from the sccache cache. Expect the Windows CI job to run approximately 2–4 minutes longer than before. This is the same situation as the AppImage workflow and is not a blocker. A follow-on actions/cache step keyed on the tarball hash could eliminate the cold-build penalty if it becomes a concern.

Testing

• @wa2n-code's local MSVC build with ENABLE_RADE=ON confirms the feature works on Windows
• Linux AppImage with an identical build path has shipped with RADE enabled for multiple releases
• CI will validate the Windows RADE build path on every PR going forward

🤖 Generated with Claude Code