Aetherial Channel Strip TX output level too low to drive radio to full PEP without high Trim

[TnxQSO-Admin]

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?

Disclaimer

This may be a radio configuration issue or user error on my part rather than an actual bug in AetherSDR. I am filing this because the investigation produced enough concrete data to suggest something might be off, and I would appreciate feedback on whether this is known/expected behavior or something to look into.

What happened

With Aetherial Audio Channel Strip as the sole TX processing (FlexRadio EQ and compressor disabled), default settings produce significantly lower-than-expected TX output power. To get close to the radio's rated PEP, Trim must be raised approximately +6.5 dB above default.

Measurements at normal speech levels with default Trim (+1 dB), limiter ceiling -3 dB, LIM on:

• Channel strip Final Output Stage: peaks at the displayed -3 dB ceiling occasionally, RMS around -20 dBFS
• Radio-side SC_MIC meter: -21 dBFS
• FWDPWR: approximately 100 W PEP from a radio rated 500 W
• TUNE (no audio processing involved): 500 W, confirming the RF chain and PA are healthy

Workaround that produces acceptable results: Trim +6.5 dB, limiter ceiling 0 dB, LIM off. Output reaches approximately 400 W PEP and a QSO partner confirmed clean audio.

Environment

• OS: Linux (Arch / KDE)
• Radio: FlexRadio AU-520 (500 W class)
• AetherSDR: built from current main
• Microphone: RØDE NT-USB
• FlexRadio EQ: OFF
• FlexRadio compressor: OFF
• DAX: OFF
• All TX processing performed in Aetherial Audio Channel Strip

Investigation

Two independent measurements were performed to narrow down where the level loss occurs.

1. Radio-side meter capture

I wrote a Python script that connects to the radio on TCP/4992 and reads every meter the firmware exposes via VITA-49 (PCC 0x8002), including meters that AetherSDR does not currently display: CODEC, TXAGC, SC_MIC, AFTEREQ, COMPPEAK, ALC, RM_TX_AGC, SC_FILT_1, SC_FILT_2, TX_AGC, FWDPWR.

With Trim +1 dB, normal speech, snapshot during TX:

SC_MIC      -21.0 dBFS
CODEC       -24.1
TXAGC       -21.0
AFTEREQ     -21.2
COMPPEAK     -6.4   (compressor disabled, but post-comp tap reads this)
ALC         -17.5
RM_TX_AGC   -20.0
TX_AGC      -20.1
FWDPWR       48.8 W

The radio TX chain passes the signal through correctly. FWDPWR is consistent with a signal arriving at SC_MIC near -21 dBFS. The radio's RF chain and PA are operating as designed.

2. Client-side PCM level capture

I added temporary debug logging in AudioEngine.cpp around line 4140 (the TX callback path), measuring peak and RMS of the int16 stereo PCM buffer at two taps:

• Pre-limiter tap (channel strip output, before applyClientFinalLimiterTxInt16)
• Post-limiter tap (same buffer that feeds the Opus encoder)

Results at normal speech levels:

Default settings (Trim +0 dB, LIM on, ceiling -3 dB):

• Pre-limiter peaks: typically -8 to -13 dBFS, best case -3 to -5 dBFS
• Pre-limiter RMS: -17 to -22 dBFS
• Pre and post taps essentially identical (limiter never engages)

With workaround (Trim +6.5 dB, LIM off, ceiling 0 dB):

• Pre-limiter peaks unchanged from above
• Post-limiter peaks regularly clip at 0.00 dBFS (LIM off, so hard clipping)
• Consistent +6.5 dB delta between pre and post taps confirms Trim is the only thing applied between them

This confirms that the channel strip output naturally lives 8 to 11 dB below the level the radio expects at SC_MIC. Trim cleanly applies that delta but has no other gain stage to do the work properly.

Related observation: WSJT-X via DAX1

A separate path observation, in case it indicates a shared upstream gain stage: WSJT-X TUNE through DAX1 with every volume slider at 100% produces only approximately 246 W. The radio's SC_MIC meter reads about -7 dBFS during the TUNE tone. This is a completely separate signal path (DAX float32, not Opus), so it should be independent of the Aetherial channel strip, yet it also shows an undersized input level relative to a full-scale tone.

Suggested fix

I do not know enough about the channel strip design intent to recommend a specific fix. Possibilities:

1. Expected behavior, undocumented. The channel strip is intentionally conservative and Trim is the intended makeup gain. In that case, either the default Trim value should be higher, or documentation/UX should make it obvious that significant Trim is normal.
2. Missing makeup gain stage. Some implicit gain stage that SmartSDR's built-in EQ/COMP provides is not replicated when those are off and Aetherial is in their place.
3. One specific processor attenuating more than intended. Less likely, but worth checking with the individual chips bypassed.

I am happy to provide additional data:

• Raw debug log CSV from /tmp/asdr_tx_levels.csv
• The Python meter-capture script
• Additional measurements with different channel strip presets, or with individual chips bypassed

Suggested labels: audio, maintainer-review, bug (or enhancement if this is expected behavior and just needs documentation or a default change).

What did you expect?

What I expected

When the channel strip is configured to peak at the limiter ceiling (e.g. ceiling at -3 dBFS, signal peaking near that level), the radio should produce close to its rated PEP. Instead, even when the Final Output Stage meter shows peaks reaching the -3 dB ceiling, the radio only delivers approximately 100 W from a 500 W class radio. To actually reach close to rated PEP, an additional +6.5 dB of Trim is required beyond what the meter says is already a fully-driven signal.

In other words: the channel strip's "0 dBFS" reference point and the radio's expected input level appear to be misaligned by roughly 6 to 10 dB.

Steps to reproduce

Steps to reproduce

1. Set up SSB TX with FlexRadio EQ and compressor OFF
2. Enable Aetherial Audio Channel Strip with default settings (or any preset)
3. Trim at default (+1 dB), limiter ceiling at default (-3 dB), LIM on
4. Adjust mic gain so that channel strip Final Output Stage shows peaks at approximately -3 dBFS during normal speech
5. Observe TX output power; it will be substantially below the radio's rated PEP

AetherSDR version

v26.5.2.1

Radio model & firmware

AU-520

Operating system

Linux

OS version and hardware

CashyOS

[aethersdr-agent]

Triage analysis

Thank you for the unusually thorough investigation — the two-tap PCM capture and SC_MIC snapshot let me confirm the diagnosis without having to ask for repro data.

Root cause: no net-positive gain anywhere in the Aetherial TX chain

The Aetherial TX path is entirely unity-or-attenuation by default. There is no makeup-gain stage between mic capture and the radio. Walking the chain in AudioEngine::onTxAudioReady (src/core/AudioEngine.cpp:3968–4220):

1. Mic capture + resample (lines 4001–4023): bit-accurate, no gain.
2. RN2 (lines 4066–4083): denoiser; unity gain when in the voice band.
3. Client TX DSP chain (applyClientTxDspInt16, line 4101, dispatched at 1894–1920): Gate → EQ → DeEss → Comp → Tube → PUDU → Reverb. Compressor enabled{false} by default (src/core/ClientComp.h:76), and makeupDb default is 0.0f (ClientComp.h:82). Every other stage in the default chain is either bypassed or unity at default settings.
4. PC mic gain (lines 4111–4118): defined in src/core/AudioEngine.h:125 as level / 100.0f, range [0.0, 1.0]. This is attenuation-only — it can never amplify. With the slider at 100 (default), gain == 1.0 and the stage is a no-op.
5. Final brickwall limiter / Trim (applyClientFinalLimiterTxInt16, line 4140): ClientFinalLimiter::process applies trimLin PRE-limiter as "drive into limiter" (src/core/ClientFinalLimiter.cpp:202–208). Trim range is [-12, +12] dB, default 0.0f (ClientFinalLimiter.h:87). With the limiter ceiling at the default -1 dB (ClientFinalLimiter.h:86) or your -3 dB, this stage is the ONLY net-positive gain knob in the entire client TX path.
6. Opus encode + VITA-49 packetise (lines 4163–4220): bit-accurate.

So your measurement is exactly what the code does:

• Mic peaks of -8 to -13 dBFS at the chip output → carried unchanged through PC mic gain (no-op at 100%) → trim +0 does nothing → limiter doesn't engage (signal under ceiling) → radio receives ~-21 dBFS RMS at SC_MIC.
• +6.5 dB of Trim is exactly the missing makeup gain. The +6.5 dB delta between pre/post taps you measured is the trim multiplier and nothing else — confirmed by ClientFinalLimiter.cpp:207–208.

The radio's MIC/PC input has no equivalent of mic boost for the PC source path — the radio's mic_level (0-100, transmit set miclevel) is ignored when mic_selection=PC (see src/gui/MainWindow.cpp:2150–2174 and the comment at 2165–2167: "radio has no hardware gain stage for PC input — client-authoritative"). So the client side is solely responsible for delivering a properly-staged signal, and Aetherial's defaults don't.

The WSJT-X / DAX1 observation is a separate, expected effect

DAX TX bypasses the entire Aetherial chain — it takes the radio-native route via AudioEngine::feedDaxTxAudio (AudioEngine.cpp:4462), with no Trim, no limiter, no makeup. The comment at lines 4466–4471 documents this is intentional ("digital modes carry pre-shaped tones"). A WSJT-X TUNE tone is typically -6 dBFS (not 0 dBFS), so SC_MIC reading -7 dBFS is consistent. From -6 dBFS you'd expect roughly 4× the power of a -12 dBFS signal, which lines up with 246 W on a 500 W-class radio that's tuned to hit rated PEP at the top of its input window. That path is not affected by this bug.

Proposed fix

Option (1) from your suggestion list — "expected behavior, undocumented" — matches the code's design intent, but the default is too low for the dominant use case (USB condenser mic, all FlexRadio processing off, Aetherial doing everything). My recommendation:

Primary fix: raise the default ClientFinalLimiter::outputTrimDb from 0.0f to roughly +6 dB, and re-anchor the default ceiling and chain so the strip's "0 dBFS reference" lines up with what the radio's remote_audio_tx Opus endpoint actually expects for full PEP. Concretely:

• src/core/ClientFinalLimiter.h:87 — change outputTrimDb{0.0f} to outputTrimDb{6.0f} (the existing +12 dB clamp at line 85 of ClientFinalLimiter.cpp accommodates this).
• src/core/AudioEngine.cpp:2987–2988 — the persisted-settings restore reads "ClientFinalLimiterTxOutputTrimDb" with default "0.0"; update the fallback string to match the new default so first-run users get the new behavior but anyone with a saved setting keeps theirs.
• Consider whether the default ceiling should move from -1 dB to -3 dB (your test config) so the boosted trim has somewhere to land without immediately overdriving — this is a UX call for the maintainer.
• Update the shipped Aetherial presets in src/core/ChannelStripPresets.cpp (the apply path at line 796 reads outputTrimDb) so any preset that currently saves 0 is bumped accordingly.

Secondary fix (UX): the "Final Output Stage" peak readout is technically correct but operationally misleading — peaks at -3 dB with RMS at -20 dB is a 17 dB crest factor, which the user reasonably reads as "fully driven" but the radio reads as "RMS down 20 dB". Adding an RMS readout next to the peak meter (or a target indicator) on StripFinalOutputPanel would head off the same confusion for the next reporter. The data is already there: ClientFinalLimiter::outputRmsDb() is computed but I don't see it surfaced in the panel UI.

Not recommended: turning Comp on by default with makeup. Too invasive; people who want a clean unprocessed pipe would notice immediately.

Handoff summary

• Known: default Aetherial TX path has no makeup gain stage; the only output-side gain knob is ClientFinalLimiter Trim, defaulted to 0 dB. With a typical USB condenser mic, the user must crank Trim to ~+6 dB to drive the radio properly.
• Fix: bump default outputTrimDb to +6 dB (one-line change in ClientFinalLimiter.h:87 plus the AppSettings fallback string at AudioEngine.cpp:2988). Optionally re-baseline the default ceiling and refresh shipped presets.
• Out of scope of this fix: the DAX/WSJT-X path is independent and not affected (no Aetherial gain there by design).
• Reporter has offered: raw CSV from /tmp/asdr_tx_levels.csv, the Python meter-capture script, and per-stage bypass measurements — useful if we want to validate the chosen +6 dB figure against multiple mic chains before locking it in.

---

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

Unresolved citations (6)

Citation	Reason
AudioEngine.cpp:2988	file not found in workspace
AudioEngine.cpp:4462	file not found in workspace
ClientComp.h:82	file not found in workspace
ClientFinalLimiter.cpp:207	file not found in workspace
ClientFinalLimiter.h:86	file not found in workspace
ClientFinalLimiter.h:87	file not found in workspace

[TnxQSO-Admin]

FWIW, two quick observations from further testing that may or may not be relevant:

1. With my mic chain, TUBE alone produced ~7 dB higher RMS than the full default-active chain, and enabling COMP actually reduced RMS rather than raising it (consistent with your triage note about the compressor dragging average power down).

2. Add PAPR-reduction phase rotator as a pre-compressor TX chain stage #2887 (PAPR phase rotator) feels directly relevant here. Even with the +6 dB Trim fix, my waveform shows ~25-30 dB crest factor at normal speech, so peaks hit the limiter while RMS stays well below. A phase rotator (or similar PAPR reduction in the default path) might be needed for a new user to actually measure decent average TX power out of the box.