FreeDV is requesting add the microphone and speaker that was already default from last use.

[marknewbill15-wq]

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?

FreeDV is requesting add the microphone and speaker that was already default from last use.
it is also listing the same item multiple times, for example - default speaker K200, then it appears below again as a highlighted selection and ask if I want it to be used. maybe that is normal, but it looked like it was considering it as a new item.

it also ask every use if I want to use my plantronics bluetooth voyager headset as the mic. once set, why cant it remember the selection? is because the voyager sleeps and wakes up?

What did you expect?

if there is no default PC mic, then ask.
if there is no defailt pc speaker, then ask

however, if that was set last time the program was used, remember the selection.
an easy place in the menu to select the audio devices like other stand alone digital mode programs would also be nice feature.

Steps to reproduce

open the program
select Raid.
it will ask for the audio devices to be set, even if they were set last usage.

AetherSDR version

26.5.2.1

Radio model & firmware

flex 8400 4.2

Operating system

Windows

OS version and hardware

windows 11

[marknewbill15-wq]

ps my default mic is hardwired to the radio, maybe that adds to the issue?

[aethersdr-agent]

Triage analysis

Root cause — three interacting issues:

1. Known-device snapshot isn't persisted across sessions. MainWindow::setupAudioDeviceChangeMonitor (src/gui/MainWindow.cpp:6375) seeds m_knownAudioInputIds / m_knownAudioOutputIds from whatever QMediaDevices reports at launch. A Bluetooth headset that's asleep (or a USB device not currently plugged in) at startup is absent from that snapshot, so when it wakes up later in the session Qt fires audioInputsChanged and handleAudioDeviceListChanged (MainWindow.cpp:6399) sees a "newly added" ID and pops the dialog — even though the user picked it weeks ago.

2. The "new device" check ignores the persisted user choice. AudioEngine::setInputDevice/setOutputDevice (src/core/AudioEngine.cpp:4321,4340) already saves the selection as AudioInputDeviceId / AudioOutputDeviceId in AppSettings, and AudioEngine::initialize (AudioEngine.cpp:574–588) restores it. But handleAudioDeviceListChanged never compares the added-IDs set against those saved IDs. If the only "new" device IS the persisted preference, we should silently re-bind to it, not prompt.

3. Why this is bad on Windows + BT specifically. Plantronics Voyager (and other BT headsets) switch between A2DP and HFP profiles when an app opens the mic. Activating RADE starts PC mic capture → Windows transitions the headset to HFP → a "new" audio endpoint is enumerated → dialog appears. Repeat every session.

Duplicate K200 listing is by design but visually confusing: AudioDeviceChangeDialog::buildDeviceSection (src/gui/AudioDeviceChangeDialog.cpp:179–210) always prepends a synthetic "System default (K200)" row, then also lists the real K200 device with a [Default] badge. When the saved selection is "follow system default" (null id), the synthetic row gets [Current] while the real K200 row is also highlighted as [Default]. To the user it looks like the same device twice.

Re: "easy place in the menu to select audio devices" — this already exists under Settings → Radio Setup → PC Audio Devices (src/gui/RadioSetupDialog.cpp:1850–1915). Discoverability could be improved (e.g., a TitleBar right-click on the PC Audio button), but the capability is there.

Proposed fix

In src/gui/MainWindow.cpp:

1. Persist m_knownAudioInputIds / m_knownAudioOutputIds to AppSettings (e.g., KnownAudioInputIds / KnownAudioOutputIds as a serialized list). Seed from the saved list at startup, fall back to the current device snapshot only if no saved list exists. Save after each change. This stops sleep/wake and replug from re-triggering the dialog across sessions.

2. In handleAudioDeviceListChanged (~line 6399), before showing the dialog, read the saved AudioInputDeviceId / AudioOutputDeviceId. If the newly-added IDs match those saved preferences, silently call applyAudioDeviceSelection(...) with the rediscovered device(s) and skip the dialog. Only prompt when a genuinely unrecognized device appears.

3. In AudioDeviceChangeDialog::buildDeviceSection (AudioDeviceChangeDialog.cpp:153), when the system-default device id matches a device already in the list, drop the synthetic "System default (...)" placeholder and just badge the real entry as [Default] (and [Current] when applicable). Eliminates the duplicate row.

The persistence fix (#1+#2) is cross-platform; it just shows up loudest on Windows + BT, which is why the platform label is set. No firmware/protocol change required.

Handoff summary

• Known: Root cause is in client code (MainWindow.cpp + AudioDeviceChangeDialog.cpp); persistence of selected devices already works, but the "newly added" detector doesn't account for persisted choices and the snapshot resets every launch.
• Fix: Persist the known-device-ID set across sessions, and suppress the dialog when the only "new" device matches the user's saved selection (auto-rebind). De-dupe the synthetic default entry in the dialog.
• Why: BT profile switching and sleep/wake re-enumerate devices mid-session, currently treated as brand-new every time.
• No protocol/firmware involvement.

---

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

Unresolved citations (3)

Citation	Reason
AudioDeviceChangeDialog.cpp:153	file not found in workspace
AudioEngine.cpp:574	file not found in workspace
MainWindow.cpp:6399	file not found in workspace

[jensenpat]

I need a screenshot on this one. I'm not sure what the core audio picker has to do with FreeDV, or why it would be triggered there.

Also Bluetooth devices can contain multiple profiles, so it's expected to see them coming from your OS. As well as Teams/Zoom and other capture devices.

[NF0T]

I don't believe this is related to RADE/FreeDV either.