Symptom

DAX IQ has never delivered samples to consumer code on Windows or Linux-without-PipeWire — neither the GUI's DaxIqApplet level meter nor any TCI IQ client receives any data, even though stream creation succeeds and the radio sends UDP packets that PanadapterStream observably receives.

Confirmed on Flex 6700 / Windows 11 / main@dfd47a8:

• Toggle DAX IQ channel 1 "On" in DaxIqApplet → no level on the meter
• Send iq_start:0; from a TCI client → 0 bytes / 0 frames received

Yet AE's own log (with DAX, Protocol/Status, Connection/Commands, VITA-49 modules enabled in Support & Diagnostics) clearly shows:

TX: "C140|stream create type=dax_iq daxiq_channel=1"
DBG aether.vita49: PanadapterStream: new stream 4128 bytes streamId=0x20000000
RX: "stream 0x20000000 type=dax_iq daxiq_channel=1 pan=0x40000000 ... active=1"
DBG aether.dax: RadioModel: DAX stream status stream=0x20000000 type=dax_iq ours=1

So the radio creates the stream and PanadapterStream receives the VITA-49 packets. But iqDataReady never fires — there is no PanadapterStream: registered IQ stream 0xNNNNNNNN log line, only registered pan stream and registered wf stream for the panadapter and waterfall respectively.

Root cause

Same class of bug as #1820 (RADE RX on Windows).

The DAX IQ stream-status registration handler — the code that calls panStream->registerIqStream(streamId, ch) when the radio confirms a stream — lives inside MainWindow::startDax(), which is gated:

#if defined(Q_OS_MAC) || defined(HAVE_PIPEWIRE)
bool MainWindow::startDax() { ... }
#endif

On Windows / non-PipeWire Linux, startDax() is compiled out entirely. Without registerIqStream, PanadapterStream receives the inbound VITA-49 IQ packets but has no channel→streamId mapping for them. iqDataReady doesn't fire. The GUI level meter stays silent (no DaxIqModel::feedRawIqPacket), and TciServer::onIqDataReady (which is connected unconditionally) never sees a single frame.

Fix

Mirror just the IQ-side wiring outside the audio-bridge gate. The DAX RX (audio) wiring genuinely needs the bridge so it stays gated as-is. The DAX IQ wiring is independent of the audio bridge — pure connect() calls between RadioModel, PanadapterStream, DaxIqModel, and DaxIqApplet, all of which exist on every platform.

The new block is conditional on #if !defined(Q_OS_MAC) && !defined(HAVE_PIPEWIRE) so we don't double-connect on platforms where startDax() still does the wiring lazily when DAX audio is toggled.

Test plan

Verified across all three build targets:

The Linux box's CMake configure prints Linux DAX bridge enabled (PulseAudio pipe modules) confirming HAVE_PIPEWIRE is undefined there too, so this PR closes the registration gap on two platforms at once, not just Windows.

Separate observation, not part of this PR

After this fix, IQ frames flow end-to-end (verified via TCI client receiving binary frames matching TciAudioHeader with type=0). However, the contents of those frames during my testing were zero-padded — 11 MB WAV file with all-zero samples even though frame headers and counts are correct.

The radio's stream status reports endpoint_type=Display and client_gui_handle == client_handle, suggesting the radio distinguishes between Display-endpoint streams (panadapter spectrum data, what AE-as-a-GUI-client gets) and DAX-endpoint streams (raw IQ samples, what SmartSDR's separate DAX-IQ utility gets via a different client identity). If that's the case, AE may need a different code path to negotiate a DAX endpoint — but that's out of scope for this PR and probably worth a separate discussion.

This PR fixes the registration gap so that whatever AE eventually does deliver gets routed to consumers (GUI applet + TCI clients). The empty-payload issue, if it's real, is downstream.

Diff summary

• One file changed (src/gui/MainWindow.cpp)
• ~52 lines added, 0 removed
• No platform-specific APIs introduced
• Direct mirror of the Fix RADE RX not decoding on Windows: create dax_rx stream in activateRADE() #1820 fix pattern (the audio analog) for the IQ side

73 de G0JKN & Claude (AI dev partner)