Thanks for the thorough review — addressed all five points (numbering below matches your review). Your preferred route (un-lazy the wiring) did collapse points 1 and 2 as you predicted.

What changed

Items 1 & 2 — un-lazy the DAX-IQ wiring. The IQ-side connections (stream-status routing, VITA-49 feed, level meter, and enable/disable/rate) are now wired once at construction on all platforms — the #if !defined(Q_OS_MAC) && !defined(HAVE_PIPEWIRE) guard is gone. They never depended on the audio bridge, so:

• startDax() no longer wires any IQ connections (it keeps only the audio-bridge wiring), and the auto-start lambda is deleted.
• A DAX-IQ channel works without first enabling DAX audio (the standalone case the lambda was papering over).
• The enable/rate connections survive a DAX-audio stop because they were never tied to the bridge's lifetime — so stopDax() can't leave a half-wired path, and the surviving-connection + lambda double-fire is structurally impossible. Connection accumulation across start/stop cycles is also gone (wired once, not per-start).

This does mean enabling DAX-IQ no longer spins up the DAX audio bridge on Mac/PipeWire (it goes straight to createStream) — intentional, since IQ rides PanadapterStream's VITA-49 path independently of the bridge (matching the Windows precedent).

Item 3 — confirmed safe, no change. m_desiredRate already inits to {48000, 48000, 48000, 48000} and IqStream::sampleRate to 48000, so the createStream-with-no-prior-setSampleRate path can't send daxiq_rate=0.

Item 4 — emit streamChanged unconditionally; suppress only the combo sync. applyStreamStatus now always emits streamChanged, so the On/Off button and meter gating sync the instant the stream exists — a radio that rejects or never echoes the daxiq_rate re-apply no longer leaves the channel stuck "Off" with the meter pinned at 0. A new IqStream::rateSettling flag suppresses only the rate-combo sync during the transient, so the user's selection never visibly flips to 48k. I tracked the flag against the actual rate gap (m_desiredRate != s.sampleRate) rather than isNew, so an interleaved non-rate status (e.g. a pan= bind arriving between the 48k create-status and the rate echo) can't prematurely clear it and flicker the combo — it self-clears exactly on the status that reaches the rate.

Item 5 — m_restorePending guard. Collapses overlapping restoreEnabledChannels() 1.5 s timers (cleared the moment the timer fires) so two scheduled within the settle window can't both pass the lagging exists guard and double-create.

Verification

• Builds clean on Linux + PipeWire (Nobara, Qt 6.10.3, gcc 15.2.1); the PipeWire path exercises the same #if defined(Q_OS_MAC) || defined(HAVE_PIPEWIRE) branch macOS compiles.
• Live A/B on a FLEX-6700 (item 1): with two DAX-audio on/off cycles before a single channel-enable, the pre-patch build sent 3 stream create type=dax_iq for that one click (one duplicate per stranded cycle); the patched build sends exactly 1, and stays at 1 regardless of how many times DAX is toggled.
• Items 4 and 5 verified by code review (their triggers — a radio rejecting a rate-set, two restore timers racing — aren't hand-reachable on the bench).

73, Ozy K6OZY
AI compute partnership: cloaked.agency — drafted with Don, our VP of Engineering agent, on the Linux dev stack (nobara-dell).

Review: DAX-stack stability, #3496 guard interactions, and audio-sink-factory impact

We took a close look at this PR specifically for (a) stability risk to the rest of the DAX stack, (b) interactions with the guards added in #3496, and (c) any impact on the audio sink factory work (#3306). Summary below.

Audio sink factory (#3306): no interaction ✅

Nothing here reaches AudioFormatNegotiator / AudioDeviceNegotiator or AudioEngine. The DAX-IQ pipe is a PipeWire module-pipe-source loaded via pactl — it never opens a Qt audio sink, never enters the format/rate negotiation ladder, and isn't part of device-following. The only shared resource is the pipewire-pulse daemon, where an extra pipe-source module can't affect sink negotiation. The staged factory migration is untouched.

DAX audio stack: net stability gain ✅

The wiring relocation fixes a latent duplicate-connection bug rather than creating one. Previously (Mac/PipeWire), startDax() wired the IQ statusReceived handler, iqDataReady feed, meter, and enable/rate connections with receiver this (MainWindow), and stopDax() never disconnected them — it only tears down bridge-receiver connections or deletes m_daxBridge (which auto-drops only the dax_rx handler). So every DAX-audio off/on cycle stacked a duplicate set of IQ connections: duplicate applyStreamStatus, duplicate pipe destroy/create, duplicate stream set commands. Wiring once at construction eliminates that. The streamStatusBelongsToUs multi-client guard is preserved, and the worker's new synchronous pactl runs on the DaxIqWorker thread, not the GUI thread.

#3496 guard interactions: none unwound or circumvented ✅

• The two PRs guard disjoint stream types in disjoint registries: fix(tci/dax): DAX RX lifecycle hotfix — stopDax ownership guard, profile-switch recreate, debounced teardown (#3363, #3364, #3476) #3496's stopDax() ownership guard and TCI debounce operate on dax_rx (m_daxStreamIds / m_tciDaxStreamIds); everything here is dax_iq (m_iqStreamIds, DaxIqModel). fix(tci/dax): DAX RX lifecycle hotfix — stopDax ownership guard, profile-switch recreate, debounced teardown (#3363, #3364, #3476) #3496's guarded removal loop can never see an IQ stream, and nothing here adds or removes a dax_rx stream.
• The new always-wired IQ handler does fire for every stream ... removed status, including dax_rx removals — but it's purely reactive (keyed no-op lookups in IQ-only maps; never sends stream remove), so it cannot defeat fix(tci/dax): DAX RX lifecycle hotfix — stopDax ownership guard, profile-switch recreate, debounced teardown (#3363, #3364, #3476) #3496's 10s grace window keeping a TCI-borrowed DAX RX stream alive.
• Philosophically the PRs pull the same direction: fix(tci/dax): DAX RX lifecycle hotfix — stopDax ownership guard, profile-switch recreate, debounced teardown (#3363, #3364, #3476) #3496 stops stopDax() from tearing down streams other consumers need; this PR removes IQ from the bridge's lifetime entirely. They edit different functions in MainWindow.cpp and should merge cleanly in either order.

One issue to fix before merge: stale exists blocks restore after reconnect ⚠️

restoreEnabledChannels() adds a guard the old restore path didn't have:

if (m_model->daxIqModel().stream(i + 1).exists) {
    continue;  // already restored
}

But nothing ever clears DaxIqModel::m_streams on radio disconnect — RadioModel's disconnect teardown clears panStream registrations etc. but never resets m_daxIqModel, and handleStreamRemoved only runs on a radio-sent removed status, which a hard disconnect never delivers. After an unexpected disconnect → auto-reconnect, exists is stale-true with a dead streamId, so the restore timer skips re-creating the persisted IQ channels — the applet shows "On" but no stream exists on the radio. (The old code re-enabled unconditionally on every connect, so it happened to recover; the stale-streamId in removeStream/setSampleRate is pre-existing, but the restore skip is new.)

Suggested fix (small, and the same shape as #3496's "erase, don't zero" cache fix on the TCI side): reset the four IqStreams (and destroy pipes) on connectionStateChanged(false) — or drop the exists skip and rely on the radio's idempotency, since the m_restorePending flag already covers the double-timer race the skip was added for.

Everything else probed — double-restore on connect (m_restorePending guard), rate re-apply loops (rateSettling tracks the rate gap and self-clears), TCI's parallel createStream/removeStream path — holds up.

💻 Generated with Claude Code (Fable 5.0) with architecture by @jensenpat

Thanks @jensenpat — fixed the stale-exists reconnect-restore in 3dca722, taking the "erase, don't zero" route you listed first.

DaxIqModel::handleDisconnect() resets all four IqStreams (struct cleared, channel index preserved, pipes destroyed on the worker thread — mirroring handleStreamRemoved) and is called from RadioModel::onDisconnected() right beside the existing panStream teardown — the spot you flagged where the teardown cleared panStream registrations but never reset m_daxIqModel. m_desiredRate is intentionally preserved, so the user's rate selection is re-applied by restoreEnabledChannels() on reconnect. The exists skip stays (it now reads correctly false after a disconnect), so the double-timer idempotence guarded by m_restorePending is unchanged. Incremental build clean.

On the merge conflict: it's #3351's MainWindow.cpp split against this branch's in-place DAX edits. Since this PR is stacked on #3521 and you both want #3521 to land first, I'll rebase onto main once #3521 merges — that way the extraction conflict resolves against the final base in a single pass rather than twice. Happy to rebase onto current main now instead if you'd prefer.

73, Ozy K6OZY

Heads-up — main moved under the #3351 MainWindow decomposition while this PR was open, so it'll need a rebase before merge. Trial-merge against current main shows a conflict in src/gui/MainWindow.cpp and src/models/RadioModel.cpp (the RadioModel hunk is unrelated churn, not from the refactor).

Good news: this is a mechanical rebase, no code changes required. I checked the diff — it doesn't reference any of the members or methods that the decomposition relocated, so the conflict is pure line-churn from MainWindow.cpp shrinking (~19.5k → ~8.1k lines across #3508–#3545).

One thing to watch when you resolve it: if your conflict hunk falls in a region that moved out of MainWindow.cpp, the new home is a sibling TU (MainWindow_Session.cpp, _Wiring.cpp, _DigitalModes.cpp, _Menus.cpp, _Controllers.cpp, _Shortcuts.cpp, _SwrSweep.cpp, _Spots.cpp, _DspApplets.cpp) — put the change there rather than back in MainWindow.cpp. Most likely your hunk is untouched and git rebase origin/main resolves cleanly.

Happy to take the rebase off your hands if you'd prefer — just say so.

Rebased fix/dax-iq-end-to-end onto current main — done, force-pushed (head 53f2dfeb).

A heads-up on one wrinkle, since it was slightly more than pure line-churn: #3521 landed as a squash, so I rebased only this PR's own seven commits onto main (the three delivered-samples commits are already in main via #3521 and dropped out). Of those seven, the un-lazy-wiring change did fall inside regions the #3351 decomposition relocated, so it wasn't a no-op rebase — but no logic changed. Specifically:

• The construction-time IQ wiring moved verbatim into MainWindow::wireDaxIq() (MainWindow_Session.cpp); the un-lazy edit (drop the #if !defined(Q_OS_MAC) && !defined(HAVE_PIPEWIRE) guard so the six IQ connects wire unconditionally, plus the comment refresh and removing the now-superseded auto-start lambda) was re-applied there.
• The lazy IQ block in startDax() (MainWindow_DigitalModes.cpp) was removed and replaced with the explanatory comment, as before.
• MainWindow.cpp itself ends up with zero net change — every IQ edit relocated into the two sibling TUs.

Verification after the rebase:

• DaxIqApplet.{cpp,h} and DaxIqModel.{cpp,h} net diffs are byte-identical to the pre-rebase branch (those files weren't touched by the decomposition), so the meter/rate/restore/handleDisconnect logic is unchanged.
• Each DAX-IQ connect() signature appears exactly once across all MainWindow*.cpp (in wireDaxIq()), startDax() carries no IQ connects, and there's no surviving auto-start lambda — i.e. no double-wire and no silently-dropped edit.
• RadioModel::onDisconnected() still calls m_daxIqModel.handleDisconnect() right after clearRegisteredStreams() (the Fix FlexControl audio wheel actions #3499 churn you flagged was elsewhere in the file; that hunk applied clean).
• Clean cmake/ninja build on Linux (Nobara 43, Qt 6.10.3, gcc 15.2.1).
• Re-verified RX-only against a FLEX-6700 on the rebased binary (a PipeWire build, so it exercises the un-lazy path the decomposition relocated): a persisted-enabled DAX-IQ channel restores on connect to exactly one stream create type=dax_iq and the radio acks the stream — i.e. wireDaxIq() is reached and the construction-time iqEnableRequested → createStream connection fires, with no double-create.

All seven commits are GPG-signed. Thanks for the offer to take the rebase — appreciated, but happy to keep it on our side.