Summary
RADE mode shows "activated" in the log and the VFO widget updates, but no audio is decoded and the sync indicator never fires on Windows (or any Linux build without HAVE_PIPEWIRE).
Root Cause
activateRADE() wires PanadapterStream::daxAudioReady → RADEEngine::feedRxAudio, but daxAudioReady only fires when the radio is actively sending dax_rx VITA-49 packets. Those packets only start flowing after the client sends stream create type=dax_rx dax_channel=N.
That command is sent inside startDax(), which is wrapped in:
```cpp
#if defined(Q_OS_MAC) || defined(HAVE_PIPEWIRE)
bool MainWindow::startDax() { ... }
#endif
```
On Windows (no HAVE_PIPEWIRE) this function does not exist. activateRADE() makes all the right signal connections but the radio never receives the stream create command, so daxAudioReady never fires and feedRxAudio is never called.
Why It Went Unnoticed
Fix
When RADE activates on a non-bridge platform, send stream create type=dax_rx directly for the RADE slice's DAX channel and register the returned stream ID with PanadapterStream. Uses the same borrow-vs-create pattern as TciServer — if a stream for that channel already exists (created by TCI), reuse it rather than creating a duplicate.
On deactivate, only send stream remove if TCI has no active clients (TCI may have borrowed the RADE-created stream; removing it would silently kill TCI audio).
Tested
Verified on Windows 11 / MinGW 13.1.0 / FLEX-8400 firmware 4.1.5:
RADE registered dax_rx ch 1 stream 0x400000b appears in log on activation- SNR indicator appears in VFO widget on signal acquisition
- Clean audio decode confirmed
Related
Summary
RADE mode shows "activated" in the log and the VFO widget updates, but no audio is decoded and the sync indicator never fires on Windows (or any Linux build without
HAVE_PIPEWIRE).Root Cause
activateRADE()wiresPanadapterStream::daxAudioReady → RADEEngine::feedRxAudio, butdaxAudioReadyonly fires when the radio is actively sendingdax_rxVITA-49 packets. Those packets only start flowing after the client sendsstream create type=dax_rx dax_channel=N.That command is sent inside
startDax(), which is wrapped in:```cpp
#if defined(Q_OS_MAC) || defined(HAVE_PIPEWIRE)
bool MainWindow::startDax() { ... }
#endif
```
On Windows (no
HAVE_PIPEWIRE) this function does not exist.activateRADE()makes all the right signal connections but the radio never receives the stream create command, sodaxAudioReadynever fires andfeedRxAudiois never called.Why It Went Unnoticed
-DENABLE_RADE=OFF, Disable RADE in Windows CI check — Opus nnet.h needs MSVC setup #825) so no automated coverageRADE mode activatedwith no error, VFO widget looks correctFix
When RADE activates on a non-bridge platform, send
stream create type=dax_rxdirectly for the RADE slice's DAX channel and register the returned stream ID withPanadapterStream. Uses the same borrow-vs-create pattern asTciServer— if a stream for that channel already exists (created by TCI), reuse it rather than creating a duplicate.On deactivate, only send
stream removeif TCI has no active clients (TCI may have borrowed the RADE-created stream; removing it would silently kill TCI audio).Tested
Verified on Windows 11 / MinGW 13.1.0 / FLEX-8400 firmware 4.1.5:
RADE registered dax_rx ch 1 stream 0x400000bappears in log on activationRelated