Thanks @jensenpat — nice quality-of-life improvement, the tooltip is a good place to surface this. The wiring through AudioEngine device-change signals + queued connections on the GUI side looks correct, and signals are properly declared under signals: (not slots:) so AUTOMOC will be happy.

A couple of small notes — none blocking:

1. Linux device-list refresh gap (worth a comment). The audioInputsChanged listener you added in AudioEngine.cpp lives inside the pre-existing #if defined(Q_OS_WIN) || defined(Q_OS_MAC) block (around line 318). That's consistent with the existing pattern (PipeWire crash workaround), so it's the right call — but on Linux the tooltip will not refresh when a device is unplugged/replugged outside of Radio Setup. Setting the device via setInputDevice/setOutputDevice still emits unconditionally, so the explicit user flow is covered. Might be worth a one-line comment noting that the auto-refresh on hotplug is Win/macOS only, to make the asymmetry obvious to the next reader.

2. Minor redundancy in the "Unavailable" fallback. MainWindow::updatePcAudioTooltip's describeDevice lambda already returns tr("Unavailable") when the device is null/empty, then TitleBar::updatePcAudioToolTip re-checks isEmpty() and substitutes tr("Unavailable") again. Not a bug — just defensive duplication. Either dropping the TitleBar-side empty check, or having setPcAudioDevices be the sole place that decides the fallback string, would be slightly cleaner. Fine to leave as-is.

3. Pre-existing, not yours to fix here: AudioEngine::inputDevice()/outputDevice() are inline getters that return m_inputDevice/m_outputDevice by value without synchronization, while writes happen on the audio thread. Your queued connection means the GUI read happens after the write completes for the normal case, so this doesn't make things worse — just flagging that the underlying race already exists.

Build/test plan in the PR description looks appropriate for a UX change of this size. LGTM as-is.

Claude here, reviewing on Jeremy's behalf.

Status

Pushed merge commit bae6d62f to your branch resolving stale-base divergence with current main. No conflicts this time — the PR's changes (AudioEngine signal additions, TitleBar tooltip method, MainWindow describe-device helper) don't overlap with the recent merges in main. Auto-merge worked cleanly.

Verified post-merge

All recent PRs preserved:

• #2572 TxMicChannelNormalizer in AudioEngine.cpp: 13 refs ✓
• #2576 Q_OS_MAC guard + m_windowMoveUsesSystem in TitleBar.cpp: 8 refs ✓ (TitleBar correctly kept its custom move logic per #2576's stated scope)
• #2578 FPS labels in SpectrumWidget.cpp: undisturbed (PR doesn't touch this file)

The feature itself

Clean, well-scoped 84-line change:

• MainWindow::updatePcAudioTooltip() (line 5894) — describeDevice lambda handles the "system default" labeling correctly: if m_audio->inputDevice() returns a null QAudioDevice (user hasn't picked one), it falls back to QMediaDevices::defaultAudioInput().description() and appends (system default). Right pattern.
• AudioEngine signal additions — inputDeviceChanged() / outputDeviceChanged() emitted at three sites:
  • setOutputDevice() line 3992 — fires when user picks a device via Radio Setup
  • setInputDevice() line 4013 — same path for inputs
  • m_mediaDevices device-list change handlers (lines 328, 345) — fires when the system device list changes (USB plug/unplug, BT pair/unpair)
• TitleBar::setPcAudioDevices() stores the names and rebuilds the tooltip via updatePcAudioToolTip(). Multi-line format:

  Routes radio receive audio through this computer.
  PC mic transmit uses the selected input device.
  Input: <name>
  Output: <name>
  

• Qt::QueuedConnection on the AudioEngine → MainWindow connections — correct since AudioEngine is on its own thread.

Coordination note with PR #2583 (audio device change dialog)

Worth flagging: #2583 removes the m_mediaDevices connection block in AudioEngine.cpp lines 309-346 (the Windows/macOS auto-restart logic — "Removed the old automatic output-list restart behavior so a user can cancel the hotplug dialog without an unexpected RX path reset"). When #2583 lands, the emit outputDeviceChanged() and emit inputDeviceChanged() calls inside that block (lines 328 and 345) will go away too.

That's fine — the setter-path emits at lines 3992 and 4013 are the canonical sites. They cover both:

• Radio Setup manual device picks
• #2583's hotplug dialog accept path (which calls setInputDevice/setOutputDevice via QMetaObject::invokeMethod)
• The device-removal fallback paths (which also call the setters)

So the tooltip will continue to update via the right path even after #2583 removes the m_mediaDevices block. Whichever PR merges first, the other's rebase should be a no-op.

Build

cmake --build build -j$(nproc) — clean, only pre-existing unrelated warnings.

Minor notes

• The lambda describeDevice is defined inside updatePcAudioTooltip rather than as a free function. Fine for a single use; would refactor to a helper if a third caller appeared.
• setPcAudioDevices then updatePcAudioToolTip — two-step API. Single-step updatePcAudioToolTip(input, output) would be simpler, but the two-step API does let TitleBar refresh the tooltip on its own (e.g., on locale change for the (system default) label translation) without re-querying the AudioEngine. Defensible either way.

Recommendation

Merge. Small UX improvement, correct signal wiring, clean coordination with the parallel #2583 work. Worth confirming on macOS that the tooltip refreshes when you change devices in Radio Setup, since that's the main user flow this is improving.

Thanks Pat — the "show the operator what AetherSDR is actually using without making them open Radio Setup" pattern is exactly the right kind of incremental UX polish. The auto-refresh on AudioEngine notifications means the tooltip stays accurate without manual hover-to-rebuild.

73, Jeremy KK7GWY & Claude (AI dev partner)

Approved — clean small UX polish, correct signal wiring.