fix(audio): name CW sidetone JACK client "AetherSDR CW Sidetone"

[Ozy311]

Summary

The CW sidetone uses the PortAudio backend, which on Linux runs over PipeWire's JACK API and registers a JACK client under PortAudio's hardcoded default name PortAudio. The sidetone sink opens alongside RX and stays open for the whole RX session, so qpwgraph / JACK patchbays / WSJT-X / FLDIGI show a persistent node literally named PortAudio with no indication it belongs to AetherSDR — the most opaque label of any AetherSDR audio node.

Fix

Call PaJack_SetClientName("AetherSDR CW Sidetone") immediately before Pa_Initialize(). The pa_jack contract requires the call precede Pa_Initialize and references (does not copy) the string, so it uses a static-lifetime const char[]. Guarded with #if defined(Q_OS_LINUX) && __has_include(<pa_jack.h>) so macOS CoreAudio / Windows WASAPI builds (no pa_jack.h, no JACK node) compile unaffected. CW sidetone is AetherSDR's only PortAudio user, so naming the process-global JACK client is unambiguous.

Why

• Completes the "every AetherSDR audio node is identifiable in patchbays" line of work alongside the merged DAX/TX pipe-naming fix (fix(dax): quote pipe source/sink properties so node descriptions survive pipewire-pulse #3438) and the still-open main RX/TX stream naming (App's own RX/TX audio streams show as generic "AetherSDR" (no node.description) in device lists #3440).
• A node named PortAudio is indistinguishable from any other PortAudio app and confuses routing in WSJT-X / FLDIGI device pickers.

Scope

• 13 lines added in one file (src/core/CwSidetonePortAudioSink.cpp).
• Linux/PipeWire-only effect (guarded); no protocol, persistence, or UX change.

Test plan

• Local incremental ninja -C build clean on Linux (Nobara 43, Qt 6.10.3, gcc 15.2.1).
• Live A/B on a FLEX-6700 (RX-only), pw-dump ground truth:
  • Baseline (upstream/main 753eb689): sidetone node client.name / node.name / node.description all read PortAudio.
  • This branch: all three read AetherSDR CW Sidetone.
• macOS CoreAudio / Windows WASAPI: compiles unaffected (guard excludes the call; no JACK node on those backends) — maintainer/secondary.

Related: #3438, #3440

---

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

[aethersdr-agent]

Reviewed the diff — this looks good. Small, well-scoped, and correctly implemented:

• Placement is right. The PaJack_SetClientName() call sits inside the if (!m_paInitialized) block immediately before Pa_Initialize(), which satisfies the pa_jack contract, and it re-runs correctly if the sink is ever re-initialized after Pa_Terminate() in the destructor.
• Lifetime is right. static const char[] satisfies pa_jack's reference-not-copy semantics; the comment documents why, which future readers will appreciate.
• The "only PortAudio user" claim is accurate. I verified CwSidetonePortAudioSink.{h,cpp} is the only code touching portaudio.h/Pa_Initialize in the tree, so naming the process-global JACK client here is unambiguous as stated.
• Guard works. Q_OS_LINUX is defined by the time the preprocessor reaches the check (the header pulls in QtCore via QString/CwSidetoneSinkBackend.h), and macOS/Windows builds are unaffected.

One non-blocking note: the __has_include(<pa_jack.h>) guard tests header presence, not whether libportaudio was actually built with JACK support. A hand-built portaudio with JACK disabled but headers installed would fail at link time on PaJack_SetClientName. All mainstream distro packages build with JACK enabled (and CI uses pkg-config portaudio), so this is a theoretical edge case — just worth knowing if a user ever reports a link error against a custom portaudio. Not asking for a change; a CMake symbol check would be heavier than this 13-line fix deserves.

Ignoring the PaJack_SetClientName return value is fine — the pa_jack implementation just stores the pointer and always returns paNoError.

Nice test plan with the pw-dump A/B ground truth, and good continuity with #3438/#3440. Thanks for the contribution, K6OZY! 73

---

_{🤖 aethersdr-agent · cost: $7.4429 · model: claude-fable-5}

[aethersdr-agent]

Reviewed the diff against the surrounding code — this looks good. Verified the details that matter for this kind of change:

• Guard evaluates correctly. The new #if defined(Q_OS_LINUX) && __has_include(<pa_jack.h>) sits after #include "CwSidetonePortAudioSink.h", which pulls in <QString>, so Q_OS_LINUX is already defined at that point. No silent no-op on Linux.
• Call ordering and lifetime are right. PaJack_SetClientName is called inside the !m_paInitialized block immediately before Pa_Initialize(), and re-runs correctly on any Pa_Terminate/re-init cycle. The function-local static const char[] satisfies pa_jack's reference-not-copy contract.
• "Only PortAudio user" claim holds. Pa_Initialize appears only in this file; AudioEngine references HAVE_PORTAUDIO for backend selection but never initializes PortAudio itself. Naming the process-global JACK client here is unambiguous as stated.
• Build safety. PortAudio comes from pkg-config (system package), and pa_jack.h is only installed when portaudio was built with JACK support, so the __has_include guard doubles as a link-safety check in practice. macOS/Windows are excluded cleanly.

One optional nit, not blocking: PaJack_SetClientName returns a PaError that's silently discarded. A failure just leaves the default name (and the 21-char name is well under JACK's 64-char limit), so this is harmless — but a qCWarning(lcAudio) on non-paNoError would match the error-logging style of the rest of this file if you want it.

Nice, tightly-scoped fix with a solid pw-dump A/B test plan — thanks for continuing the patchbay-identifiability work from #3438, @Ozy311!

---

_{🤖 aethersdr-agent · cost: $4.8654 · model: claude-fable-5}