QSO Audio Recording

[Run0ff]

Request preparation

• I used an AI assistant to help structure this request
• I checked for existing issues covering the same feature

What would you like?

Some handy features for general voice work. Checking QSO details. Mobile operation without a logbook.

Possible to add feature set.
1: Option to record QSO on SSB (and I guess other modes if wanted) and output a .mp3 File
2: MOX/VOX triggers Audio recording.
3: Waits for 2 Min (option to set wait time) of no TX Activity then stops. Manual Option to stop recording.
4: Save the File with a filename including Time Date Frequency and Mode. (maybe some tick boxes to choose what is included in filename).
5: Text box for QSO callsign, if used add Callsign to filename.
6: Option to playback QSO locally or transmit the .mp3 via DAX or TCI with option to stop early.
7: Have a popout with previous recordings listed and playable , filename editable and deletable , (kind of audio QSO log).
8: Option to export a .ADIF using the Recorded QSO log as data.
9: Folder location for Recordings and .ADIF editable

[aethersdr-agent]

Thanks for the detailed feature request! This is a substantial feature set — essentially a QSO audio recorder with logging capabilities. Here's my triage analysis.

Current State

AetherSDR has no existing audio recording infrastructure. The relevant pieces we'd build on:

• AudioEngine (src/core/AudioEngine.h) — handles RX/TX audio as 24kHz int16 stereo PCM via feedAudioData() (RX from radio) and onTxAudioReady() (TX from mic). Both RX and TX PCM flow through this class, so it's the natural tap point.
• TransmitModel (src/models/TransmitModel.h) — tracks MOX/VOX state with isTransmitting(), isMox(), and emits moxChanged(). This provides the TX activity signal needed for auto-start/stop triggers.
• VirtualAudioBridge (src/core/VirtualAudioBridge.cpp) — shared-memory DAX bridge, relevant for the playback-via-DAX feature (item 6).
• AppSettings — would store recording preferences (folder path, filename format, idle timeout).

Feasibility & Scope Breakdown

This request contains 9 distinct sub-features. I'd suggest splitting into phases:

Phase 1 — Core Recording (items 1–5)

• New class QsoRecorder in src/core/ that taps into AudioEngine::feedAudioData() (RX) and the TX PCM path to capture both sides of a QSO into a single interleaved recording.
• WAV output is straightforward (Qt has no MP3 encoder; we'd either use libmp3lame as an optional dependency, or output WAV and let the user convert). Question: is WAV acceptable as a first pass, or is MP3 a hard requirement?
• MOX/VOX trigger: connect to TransmitModel::moxChanged() to auto-start recording on first TX.
• Idle timeout: a QTimer restarted on each TX→RX transition; fires after configurable delay (default 2 min) to stop recording.
• Filename: compose from QDateTime, SliceModel::frequency(), SliceModel::mode(), and optional callsign field.

Phase 2 — Playback & Management (items 6–7)

• Playback locally is straightforward via QAudioSink.
• Playback via DAX/TCI would route through VirtualAudioBridge or TciProtocol — more complex, especially the "transmit recorded audio" path which needs MOX coordination.
• Recording manager UI as a popout/applet (similar to existing FloatingAppletWindow pattern).

Phase 3 — ADIF Export (items 8–9)

• ADIF is a well-defined text format. We'd generate it from the recording metadata (date, time, freq, mode, callsign).
• This is essentially a minimal QSO logger — worth noting that full logging integration (e.g., with external logbooks) is a separate concern.

Questions for the Reporter

1. WAV vs MP3: MP3 encoding requires adding libmp3lame as a dependency. Would WAV (or Opus/OGG, which we already have codec support for) be acceptable alternatives?
2. Both sides of the QSO: Should the recording capture both RX audio (what you hear) and TX audio (what you transmit), mixed into one file? Or just RX?
3. Multi-slice: If multiple slices are active, should recording be per-slice or just the active slice?
4. Priority: Which items are must-haves vs nice-to-haves? If we ship Phase 1 first, would that be useful on its own?

Architecture Note

This feature falls under new architecture (new threads for encoding, new UI, new file I/O) and new feature scope, so per project guidelines it needs maintainer design review before implementation begins. Tagging as enhancement.

[Run0ff]

WAV vs MP3: MP3 encoding requires adding libmp3lame as a dependency. Would WAV (or Opus/OGG, which we already have codec support for) be acceptable alternatives? Answer : WAV is fine but .mp3 maybe handy for space if saving to mobile device
Should the recording capture both RX audio (what you hear) and TX audio (what you transmit), mixed into one file? Or just RX? Answer : Both RX and TX to be recorded
Multi-slice: If multiple slices are active, should recording be per-slice or just the active slice? Answer: No just current active TX slice
Priority: Which items are must-haves vs nice-to-haves? If we ship Phase 1 first, would that be useful on its own Answer : Phase 1 and 2 probably need to be together. Phase 3 after.

[aethersdr-agent]

Claude here — fix applied in PR #1298: #1298

What was changed: Add QSO audio recorder with auto-record on TX (#1297)

Files touched:

• CMakeLists.txt
• src/core/QsoRecorder.cpp
• src/core/QsoRecorder.h
• src/gui/MainWindow.cpp
• src/gui/MainWindow.h

— AetherClaude (automated agent for AetherSDR)

[ten9876]

Claude here — the backend engine for QSO audio recording is merged into main. This covers items 1-5 and 9 from your request: WAV recording, auto-record on TX, idle timeout, smart filenames, and configurable recording directory.

Still to come as follow-up work: playback UI (item 6), recording browser (item 7), and ADIF export (item 8). Will be in the next release.

73, Jeremy KK7GWY & Claude (AI dev partner)