fix(audio): default client TX final limiter to off so AetherSDR matches SmartSDR drive level#3004
Merged
ten9876 merged 1 commit intoMay 23, 2026
Conversation
…es SmartSDR drive level The ClientFinalLimiter at the tail of the PC mic voice TX chain has been enabled-by-default with a -1.0 dBFS ceiling. SmartSDR has no equivalent client-side brickwall — it sends mic audio essentially raw and lets the radio's SW ALC set the working point off the natural voice peaks. The mismatch shows up as 'less forward power from AetherSDR than from SmartSDR' on user reports: peaks above -1 dBFS get pulled down before the radio sees them, the radio's SC_MIC (#26) reads ~1 dB lower than SmartSDR's, SW ALC works off a lower reference, and average drive falls accordingly. Default the limiter to off so a fresh install matches SmartSDR's drive level. Users who want headroom protection — most relevant when running hot Comp/Tube/PUDU/Reverb on the AetherialAudio chain — can still flip LIM on in the Aetherial Final Output Stage panel at the bottom of the channel strip. Existing users whose setting was already persisted keep their previous behavior unchanged (AppSettings::value returns the persisted value, not the new default). DAX/TCI and RADE TX paths were already bypassing the limiter, so digital-mode drive is unaffected by this change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Looks good — a clean one-line default flip with a clear Why: comment explaining the SmartSDR parity goal.
Verified the reasoning against the code:
AppSettings::value("ClientFinalLimiterTxEnabled", ...)only consults the default when the key is missing, so persisted users keep their setting — no migration needed.StripFinalOutputPanel.cpp:647initializes the LIM checkbox fromlim->isEnabled()afterloadClientFinalLimiterSettings()runs, so the UI on a fresh install will correctly show LIM off and the OFF state will persist on first save.- DAX/TCI and RADE TX paths already bypass
m_clientFinalLimiterTx, so digital-mode drive is unaffected as claimed. ClientFinalLimiter's in-memory atomic still defaults toenabled=trueat construction, but that's only relevant beforeloadClientFinalLimiterSettings()runs — the load step authoritatively sets state from settings, so no audio is processed with the wrong state.
Nice catch on the SC_MIC #26 reference correlating with the ~1 dB drive delta — that's the kind of measurable evidence that makes a default change defensible. Thanks @ten9876.
🤖 aethersdr-agent · cost: $4.0990 · model: claude-opus-4-7
5 tasks
G6PWY-Chris
pushed a commit
to G6PWY-Chris/AetherSDR
that referenced
this pull request
Jun 22, 2026
…es SmartSDR drive level (aethersdr#3004) The ClientFinalLimiter at the tail of the PC mic voice TX chain has been enabled-by-default with a -1.0 dBFS ceiling. SmartSDR has no equivalent client-side brickwall — it sends mic audio essentially raw and lets the radio's SW ALC set the working point off the natural voice peaks. The mismatch shows up as 'less forward power from AetherSDR than from SmartSDR' on user reports: peaks above -1 dBFS get pulled down before the radio sees them, the radio's SC_MIC (aethersdr#26) reads ~1 dB lower than SmartSDR's, SW ALC works off a lower reference, and average drive falls accordingly. Default the limiter to off so a fresh install matches SmartSDR's drive level. Users who want headroom protection — most relevant when running hot Comp/Tube/PUDU/Reverb on the AetherialAudio chain — can still flip LIM on in the Aetherial Final Output Stage panel at the bottom of the channel strip. Existing users whose setting was already persisted keep their previous behavior unchanged (AppSettings::value returns the persisted value, not the new default). DAX/TCI and RADE TX paths were already bypassing the limiter, so digital-mode drive is unaffected by this change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ClientFinalLimiter at the tail of the PC mic voice TX chain has
been enabled-by-default with a -1.0 dBFS ceiling. SmartSDR has no
equivalent client-side brickwall — it sends mic audio essentially raw
and lets the radio's SW ALC set the working point off the natural
voice peaks.
The mismatch shows up as 'less forward power from AetherSDR than from
SmartSDR' on user reports: peaks above -1 dBFS get pulled down before
the radio sees them, the radio's SC_MIC (#26) reads ~1 dB lower than
SmartSDR's, SW ALC works off a lower reference, and average drive
falls accordingly.
Default the limiter to off so a fresh install matches SmartSDR's
drive level. Users who want headroom protection — most relevant when
running hot Comp/Tube/PUDU/Reverb on the AetherialAudio chain — can
still flip LIM on in the Aetherial Final Output Stage panel at the
bottom of the channel strip. Existing users whose setting was already
persisted keep their previous behavior unchanged (AppSettings::value
returns the persisted value, not the new default).
DAX/TCI and RADE TX paths were already bypassing the limiter, so
digital-mode drive is unaffected by this change.
Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com