Linux Pipewire causes pop-up for device changes

[N1NAZ]

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

@AetherClaude @ten9876 @jensenpat
Keep getting this popup even after re-selection, It will still pop up after a few minutes to a hour later.

What did you expect?

Not to have this pop up never did before.

Steps to reproduce

Start AetherSDR image wait, requester will pop up

AetherSDR version

v25.5.2.1 image file

Radio model & firmware

Flex 6600 V4.2.18

Operating system

Linux

OS version and hardware

Mint Cinimmon 22.3

[aethersdr-agent]

Triaged.

Root cause

The pop-up is the "Audio Device Detected — New device detected" dialog (src/gui/AudioDeviceChangeDialog.cpp), wired up in MainWindow::handleAudioDeviceListChanged() (src/gui/MainWindow.cpp:6399-6477). It was added in #2583 (commit 2cd4db8c, May 2026), which lines up with "never did before" — v25.5.2.1 is the first image release carrying that change.

The trigger logic is:

// MainWindow.cpp:6413-6448
const QList<QByteArray> addedInputIds  = newlyAddedAudioDeviceIds(inputDevices,  m_knownAudioInputIds);
const QList<QByteArray> addedOutputIds = newlyAddedAudioDeviceIds(outputDevices, m_knownAudioOutputIds);
...
const bool deviceAdded = !addedInputIds.isEmpty() || !addedOutputIds.isEmpty();
if (!deviceAdded) { ... return; }

m_audioDeviceDialogOpen = true;
AudioDeviceChangeDialog dialog(...);

newlyAddedAudioDeviceIds (line 248) considers any QAudioDevice::id() not seen since the last check to be a "new device." On Linux Mint 22.3, the audio stack is PipeWire with the pipewire-pulse shim. That stack churns out audio nodes whose Qt-visible IDs change over time:

• PulseAudio/PipeWire monitor sources (alsa_output.*.monitor) appear/disappear as sinks come and go.
• Per-application sinks created by browsers, music players, Discord, etc. (Firefox creates an ephemeral sink per <audio> element on some configs).
• Bluetooth headset reconnects (a2dp ↔ hfp profile flips create fresh node IDs).
• HDMI/DP route changes when the monitor goes to sleep.

Each of those events makes addedInputIds or addedOutputIds non-empty even though no human-relevant hardware has appeared — so the modal pops again "a few minutes to an hour later," exactly as reported. Re-selecting in the dialog doesn't help because the next transient node has a different ID.

There is a 750 ms debounce on the QMediaDevices signal (m_audioDeviceChangeTimer, line 6380), but it only coalesces rapid bursts; it doesn't filter out semantically-uninteresting changes.

Proposed fix

Tighten the gate in MainWindow::handleAudioDeviceListChanged() so the modal only appears when the user actually needs to make a decision:

1. Suppress when current selection is still valid. If both currentInput and currentOutput are present in the refreshed device lists (or are the system default and the system default still resolves), don't prompt. Just silently absorb the new IDs into m_knownAudioInputIds / m_knownAudioOutputIds. This is the dominant Linux case.
2. Filter virtual / monitor devices before computing addedInputIds / addedOutputIds. On Linux, drop devices whose QAudioDevice::id() contains .monitor, starts with pulse_input_loopback, or matches PipeWire's auto-null sink naming. (These are never useful as a PC mic / local speaker.)
3. (Optional, smaller surface) Add a "Don't ask me again" checkbox that writes an AppSettings flag (AudioHotplugPrompt = False) so users on noisy audio stacks can opt out entirely. The existing "Audio Devices…" entry in Settings remains the manual escape hatch.

Files to change: src/gui/MainWindow.cpp (the helpers around line 231-280 and the gate at 6441), plus src/gui/AudioDeviceChangeDialog.{h,cpp} if we add the suppression checkbox. No protocol/FlexLib changes.

Handoff summary

• Known: popup is AudioDeviceChangeDialog, fires whenever any audio-device ID not in m_knownAudio{Input,Output}Ids appears; PipeWire on Linux Mint generates such IDs continuously.
• To fix: gate the modal on "user choice required" (current selection missing) rather than "any new ID seen," and/or filter known-transient device-id patterns. Add a persistent opt-out as belt-and-suspenders.
• Why: the current behavior is correct for Windows/macOS hotplug (a new USB headset) but is essentially spammy noise on Linux PipeWire systems, which is now a supported install target (Mint image release).
• Not upstream: FlexLib / firmware are not involved; this is entirely client-side.

@N1NAZ — to confirm, the dialog you're seeing has the header "Audio device / New device detected" and two lists labeled Input Device and Output Device, right? If so, no further info needed; if it's a different dialog, please reply with the dialog's title-bar text.

---

_{📍 Citation health check (Foundry Constitution Principle I): 1 resolved, 1 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (1)

Citation	Reason
MainWindow.cpp:6413-6448	file not found in workspace

[N1NAZ]

@AetherClaude Yes that is what I'm seeing.

[aethersdr-agent]

Thanks for confirming, @N1NAZ — that's the dialog. Triage analysis holds: PipeWire on Mint constantly churns transient node IDs (monitor sources, per-app sinks, BT a2dp↔hfp flips), so newlyAddedAudioDeviceIds() keeps returning non-empty even though no real hardware appeared, and the modal re-fires.

Here's a focused fix for src/gui/MainWindow.cpp that tightens the gate without changing the dialog itself. Two pieces: (a) a Linux-aware filter that drops monitor/loopback/null-sink IDs before they ever count as "new"; (b) a "user choice required" check so the modal only appears when the current selection actually went away or a real device showed up.

// Near the audioDeviceIds() helpers around line 231-257:

bool isTransientAudioDeviceId(const QByteArray& id)
{
#ifdef Q_OS_LINUX
    // PipeWire / pulse-shim produces these constantly as apps come and go.
    // None of them are useful as a PC mic or local speaker target.
    if (id.contains(".monitor"))                    return true;
    if (id.startsWith("pulse_input_loopback"))      return true;
    if (id.contains("auto_null"))                   return true;  // PipeWire fallback sink
    if (id.contains("echo-cancel"))                 return true;  // module-echo-cancel virtual
    if (id.contains("combined"))                    return true;  // module-combine-sink virtual
#endif
    Q_UNUSED(id);
    return false;
}

QList<QByteArray> audioDeviceIds(const QList<QAudioDevice>& devices)
{
    QList<QByteArray> ids;
    ids.reserve(devices.size());
    for (const QAudioDevice& device : devices) {
        if (isTransientAudioDeviceId(device.id()))
            continue;
        ids.append(device.id());
    }
    return ids;
}

QList<QByteArray> newlyAddedAudioDeviceIds(const QList<QAudioDevice>& devices,
                                           const QList<QByteArray>& knownIds)
{
    QList<QByteArray> added;
    for (const QAudioDevice& device : devices) {
        if (isTransientAudioDeviceId(device.id()))
            continue;
        if (!containsAudioDeviceId(knownIds, device.id()))
            added.append(device.id());
    }
    return added;
}

Then in handleAudioDeviceListChanged() (around the deviceAdded gate at line 6441), require that the user's current selection is missing before prompting — if the user's chosen input and output are still present in the refreshed lists, the new device is just background noise from the audio stack and we should silently absorb it:

const bool currentSelectionStillValid =
    (currentInput.isNull()  || audioDevicePresent(inputDevices,  currentInput)) &&
    (currentOutput.isNull() || audioDevicePresent(outputDevices, currentOutput));

const bool deviceAdded = !addedInputIds.isEmpty() || !addedOutputIds.isEmpty();
const bool userChoiceRequired = deviceAdded && !currentSelectionStillValid;

if (!userChoiceRequired) {
    if (resetInput || resetOutput)
        resetMissingAudioDevicesToDefault(resetInput, resetOutput, reinitializePcInput);
    return;
}

This keeps Windows/macOS USB-headset hotplug working (where a new device usually arrives because the old one was unplugged, so the selection becomes invalid), and stops the spam on PipeWire (where the user's selected device is virtually always still present when a transient node appears).

If you'd also like the belt-and-suspenders opt-out, add a QCheckBox* m_dontAskAgain to AudioDeviceChangeDialog, persist its state via AppSettings, and early-return in handleAudioDeviceListChanged() when the flag is set — but I'd land the gate fix first and see if the opt-out is still needed.

A maintainer can authorize the orchestrator to land this fix by adding the aetherclaude-eligible label.

73, Jeremy KK7GWY & Claude (AI dev partner)

[jensenpat]

@AetherClaude file a PR with this fix