@RiskAndReward1337 Can you split the main window thread priority change into a separate PR for testing? I don't want to introduce instability in other non-Linux DAX / TCI use cases.

@jensenpat done — split into #2318. The MainWindow.cpp Qt::DirectConnection swap is now the only change in that PR so it can be reviewed/tested in isolation against non-Linux DAX / TCI use cases.

This PR has been rebased onto current upstream/main (ef84ad5) and the MainWindow.cpp hunk dropped — the bridge-side atomic conversions stay here as a prereq for #2318. Build is clean (Qt 6.11.0, RelWithDebInfo).

Recommended merge order: this PR first (so PipeWireAudioBridge::feedDaxAudio is lock-free), then #2318. I flagged in #2318 that VirtualAudioBridge::feedDaxAudio should be reviewed by someone with macOS hardware before merging that one.

Claude here on Jeremy's behalf — really nice writeup, and the architectural direction (native pw_stream + DirectConnection on the audio fast path) is sound. The 400 → 200 ms result with explicit identification of where the remaining latency lives (consumer-side libpulse fragsize, not in your pipeline) is exactly the level of rigor we love to see. Account checks out, no security concerns in the diff (Dockerfile / CMake / pactl call sites are all clean, no shell-injection surface introduced).

A few items to address before merge — the first is a real (rare) data race; the rest are smaller:

Must-fix:

1. SPSC ring invariant is violated. PipeWireNativeRxSource.h:980-985 documents "Producer writes m_writeIdx; consumer writes m_readIdx", but the overflow path in PipeWireNativeRxSource.cpp:838 calls m_readIdx.fetch_add(drop, std::memory_order_release) from the producer side. Two writers to m_readIdx is no longer SPSC: when onProcess is mid-memcpy from [oldR..oldR+toRead-1] and the producer's drop advances m_readIdx past the slot about to be overwritten by the wrap, you get a torn read. Only triggers when the consumer stalls and the producer overflows in the same window — rare, but it's a real race the docs explicitly say can't happen. Suggested fix: drop new samples on overflow instead, or expose a separate atomic drop counter and let the consumer detect the gap on its next read.

2. Raw new for the listener hook. PipeWireNativeRxSource.cpp:761: pw_stream_add_listener(m_stream, new spa_hook{}, &kStreamEvents, this). The project's CLAUDE.md style guide rules out raw new/delete — and besides, this leaks a hook per open() call. spa_hook is POD; just make it a member (spa_hook m_listenerHook{};) and pass &m_listenerHook.

Worth fixing while you're in there:

3. PipeWireNativeContext::acquire() race. PipeWireNativeContext.cpp:475 — if thread B's fetch_add returns 1 while thread A is still mid-init (post-fetch_add, pre-m_loop = ...), B sees m_loop == nullptr and returns false even though init is in progress. Header comment says "Safe to call from any thread"; today they're effectively serialized through the main thread, but a std::once_flag or short mutex around init/teardown matches the documented contract.

4. reinterpret_cast of the state-changed callback. PipeWireNativeRxSource.cpp:665 casts an (int, int, ...) signature to libpipewire's (enum pw_stream_state, enum pw_stream_state, ...) — works on Linux x86_64/aarch64 because the enums are int-sized, but it's UB in strict C++. Just declare onStateChanged with the enum types and drop the cast.

5. Stale doc. PipeWireNativeRxSource.h:957 says "caps backlog at the ring size (~170 ms)" but RING_SIZE = 2048 / 48000 ≈ 42 ms. The 170 ms number is from the earlier 8192 sizing.

Nice-to-have, not blocking:

• Run CI on the branch so the Linux build path with libpipewire-0.3-dev gets validated end-to-end before merge.

Once #1 and #2 are addressed I'd be happy to give a fresh pass and recommend merge. The latency win is meaningful and the rest of the work is genuinely careful — the upsampler's cross-packet prev retention and TX-gap reset detail in particular is the kind of thing easy to miss.

73, Jeremy KK7GWY & Claude (AI dev partner)

@ten9876 Thanks Jeremy & Claude — that's a really sharp review, especially catching the SPSC violation. All five items addressed in 2cf2d15:

Must-fix #1 — SPSC ring race. Switched to drop-newest in feedAudio(). m_readIdx is now consumer-only as the docs claim. The 42 ms latency cap is preserved; the only behavioural change is which samples get dropped during a consumer stall, and in steady state the ring is near-empty so the choice doesn't matter. I went with the simpler of your two suggestions (drop-newest) rather than the gap-counter option because consumer stalls only occur under extreme system load in this codepath, so the rare drop-oldest-vs-drop-newest distinction isn't worth the extra coordination.

Must-fix #2 — raw new spa_hook. Made it a by-value member (spa_hook m_listenerHook{}). Lifetime now matches the RxSource itself, no leak across re-open() calls, and complies with the no-raw-new rule in CLAUDE.md. Pulled <spa/utils/hook.h> into the header for the member type.

Worth-fixing #3 — acquire() race. Wrapped init/teardown bodies in a std::mutex. m_refCount is no longer atomic since it's now under the lock — plain int is sufficient. The "safe from any thread" header contract is now real instead of incidentally true via main-thread serialisation.

Worth-fixing #4 — reinterpret_cast UB. Replaced with an anonymous-namespace trampoline (onStateChangedTrampoline) that has the correct C signature (enum pw_stream_state args) and forwards via static_cast<int> into the static member. Header stays free of <pipewire/stream.h>.

Worth-fixing #5 — stale doc. Comment on feedAudio() now correctly says "~42 ms" and reflects the new drop-newest semantics + SPSC invariant.

CI. The previous push's CI run on this branch was green (#25286904608). The new push's run is currently in action_required waiting on maintainer approval.

Builds clean locally on Qt 6.11.0 / RelWithDebInfo with no new warnings on the four touched files. Verified the binary still drives DAX correctly post-changes.

Ready for a fresh pass whenever convenient. Thanks for the careful read — that ring race genuinely could have shipped.

Claude here on Jeremy's behalf — merged via admin squash. All five review items cleanly addressed in 2cf2d15; the SPSC fix in particular landed exactly the way you described.

Jeremy is going to run the hardware smoke test on his FLEX-8600 + Linux PipeWire setup against WSJT-X. We'll holler back here if the on-radio path surfaces anything — your fallback to legacy module-pipe-source on per-channel open() failure means worst case is "no latency improvement," not "DAX broken."

Thanks for the careful workmanship and the well-reasoned writeup. The 400 → 200 ms result with explicit identification of the remaining consumer-side libpulse fragsize gap is the kind of detail that makes review easy.

73, Jeremy KK7GWY & Claude (AI dev partner)