HL2 TX: the "ALC" applies up to 40 dB of upward makeup with an absolute hold threshold, so room noise is transmitted level with speech

[on8st]

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?

Operating SSB on a Hermes-Lite 2, the transmitted signal rose on its own during
pauses. In the operator's words:

the ssb tx signal went way up without me saying anything. When not talking you
expect ssb to be close to silent.

Reproduced on the operator's own voice, AirPods in both directions, keyed
against a simulator, mic slider 70:

• The ALC's gain climbs 16.65 → 30.70 dB inside a single pause.
• On two of three pauses the output contrast between pause and speech collapses
  to 0.00 dB, with the transmitted level pinned at −1.41 dBFS — which is
  alcTargetPeak 0.85 exactly.

What triggered it was not the room. Their AirPods' steady floor is clean:
p50 −60.33 dBFS even at slider 90, fifteen dB below the −45 dBFS hold
threshold, with zero blocks above it. What crossed were transients inside
the pauses — block maxima of −31.6 and −23.9 dBFS against a steady floor
near −65.

At −31.6 dBFS the makeup the ALC wants is alcTargetPeak / blockPeak, about
+30 dB. So a breath, or a shift in the chair, is treated as a syllable and
lifted toward full modulation — and because only a louder block can bring
the gain back down, it stays there for the rest of the pause.

That is the operator's complaint, precisely: not that a noisy room gets
amplified, but that one small sound during a pause pins the transmitted noise
at speech level until they speak again.

The hold is not broken — it is one-way. At slider 90, where nothing crossed
the threshold at all, it worked exactly as designed and the gain froze to the
second decimal (27.27 → 27.27, 27.46 → 27.46) with contrast held at
28.5–28.7 dB. The failure is not that the hold fails to engage. It is that a
single crossing is irreversible.

The same mechanism, the other way in

On a hotter microphone the steady floor itself crosses. Reproduced in a digital
loopback with a −53 dBFS room floor and the slider at 100, which raises that
floor after the voice strip:

measured at the ALC	pause	speech	separation
input	−37.05 dBFS	−12.4 dBFS	20.5 dB
output	−1.38 dBFS	−1.05 dBFS	0.33 dB

An input separation of 20.5 dB leaves as 0.33 dB.

Two devices, two routes, one mechanism:

An absolute threshold on an instantaneous block peak cannot distinguish a
breath from a syllable.

Mechanism

In Hl2TxDsp, the makeup half of the ALC lifts each block toward
alcTargetPeak (0.85, −1.4 dBFS) with a ceiling of alcMaxGainDb (40 dB)
and a 500 ms release. It stops lifting only while

const bool held = !reducing && !clientLeveled && blockPeak < holdThreshold;

where holdThreshold comes from alcHoldBelowDbfs = −45.0.

Three properties combine:

1. The threshold is absolute, not relative to the programme. The same file
   notes that "speech sits around -32 dBFS", so anything between −45 and
   −32 dBFS is treated as loud enough to be speech and is lifted toward 0.85 —
   a ~13 dB window in which a noise floor is indistinguishable from a talker.
2. It is applied to an instantaneous block peak. A breath at −31.6 dBFS and
   a syllable at −31.6 dBFS are the same number, so the stage cannot tell them
   apart — and it lifts both toward full modulation.
3. Within a pause there is no path down. The gain ratchets up on any block
   that crosses, and the hold only prevents further lifting; it does not undo
   what has been applied. Only a louder block can pull the gain back down,
   and a pause is precisely what does not contain one. Reduction itself is never
   held, so the gain does come back at the next burst — the fault is not a level
   that runs away across the over, it is noise transmitted at speech level for
   the whole of every pause.

A second route reaches the same place on hotter microphones: the threshold is
compared after the operator's mic gain, and the slider exists partly to
carry a quiet microphone over this very threshold — the code says so — so
raising gain to be heard is also what pushes a steady room floor across it.
That is the route the loopback above reproduces. Both routes are the same
defect: an absolute threshold on an instantaneous peak, with no way back
down.

What did you expect?

Pauses to be close to silent on SSB, and any automatic level control ahead of a
transmitter to reduce gain rather than add it.

On the name, structurally rather than rhetorically

In amateur-radio usage an ALC — internal or external — is a feedback loop
around a power amplifier that gain-limits to protect the finals. This stage
has no amplifier in its loop: it acts on audio before the modulator. It applies
up to 40 dB of upward makeup, and it is continuously engaged rather than
rarely.

Whatever this stage is, it is not an ALC, and the name is plausibly why it has
no operator controls — a protective limiter would not need any. It is a
leveller, and calling it one would make the design question visible.

The application cannot know whether the capture device levels

Whether a capture device applies its own AGC is not knowable to the
application, and differs by device — which the two devices measured here
already demonstrate. The operator transmits on AirPods, whose floor sits at
p50 −60.33 dBFS, fifteen dB below the hold threshold, and which crosses on
transients rather than on its floor. A USB webcam microphone on the same machine
(Logitech 4K Stream Edition) behaves differently again; 30 s of silence from it,
in 3-second blocks:

RMS   -67.63  -67.62  -68.03  -67.81  -67.74  -67.73  -67.79  -68.07  dBFS
peak  -53.16  -54.75  -55.35  -54.75  -54.19  -54.75  -54.75  -55.35  dBFS

Flat to 0.45 dB RMS and 2.2 dB peak over thirty seconds — no gain riding at
all. A winding AGC climbs during sustained silence, which is exactly the
signature the stage under discussion shows. This device does not do it.

What that measurement does not show: it does not prove the absence of AGC.
An AGC may legitimately hold during pure silence — the stage complained about
here does exactly that below its own threshold. Establishing it either way needs
a level step: present the same signal at two very different acoustic levels
and check whether the recorded ratio matches the presented one. That test has
not been done, so for this device the question is open.

So a fixed 40 dB of makeup, applied blind, is wrong in both directions:

• On a device that levels, it is a second loop chasing the first.
• On a device that does not — like the one measured above — the makeup is doing
  real work, and the fault is not that it exists. The fault is that it cannot
  be told to stop during pauses, and cannot be seen or adjusted at all.

None of this means nothing is wanted ahead of an SSB transmitter. SSB is
peak-power limited while intelligibility rides on average power, and unprocessed
voice runs ~17 dB peak-to-average, so compression, a genuine protective limiter
and band-limiting are all still wanted. Levelling and compression are different
jobs: levelling makes the average consistent, compression changes the crest
factor.

And AetherSDR already has all three, properly. AetherVoice provides a
compressor, gate, EQ, de-esser and final limiter — visible, adjustable,
operator-ordered. (They ship off: ClientFinalLimiterTxEnabled defaults to
"False" like the rest of the strip, so nothing in this issue assumes any of
them is running.) Hl2TxDsp adds a fourth stage that is invisible and
unadjustable, whose behaviour depends on a property of the capture device that
the application never establishes.

Steps to reproduce

1. Feed the HL2 TX path a signal with a quiet noise floor and speech-like
   bursts — a floor around −53 dBFS with bursts peaking near −12 dBFS
   reproduces it.
2. Set the microphone gain slider high enough that the floor arrives at
   Hl2TxDsp above −45 dBFS (slider 100 with the above).
3. Compare pause-to-speech separation at the input of the ALC and at its output.

Here that is 20.5 dB in and 0.33 dB out.

Operator workaround, which does work: enabling the client gate/expander ahead
of the ALC drops the floor at the ALC by 12.6 dB (−37.05 → −49.69 dBFS), back
under the hold threshold, and is transparent on speech at ordinary settings
(level +0.09 dB, spread 19.71 → 19.53 dB). It is a workaround rather than a fix —
it requires knowing the interaction exists.

AetherSDR version

26.9.1

Radio model & firmware

Hermes-Lite 2, gateware 20231230_74p2_883a338

Operating system

macOS

OS version and hardware

macOS 26.6.2, Apple M2, Qt 6.8.3

---

Suggested fix — converge on the reference implementation

The library AetherSDR already vendors makes exactly the distinction this stage
collapses. In third_party/wdsp/upstream/TXA.c, create_txa() builds
two wcpagc instances at two points via create_wcpagc, with these constructor arguments and
these comments:

txa[channel].leveler.p = create_wcpagc (
    0,          // run - OFF by default
    ...
    0.500,      // tau_decay
    1.778,      // max_gain          (+5.0 dB)

txa[channel].alc.p = create_wcpagc (
    1,          // run - always ON
    ...
    0.010,      // tau_decay
    1.0,        // max_gain          (+0.00 dB)

The stage named ALC is always on and has a unity ceiling — it is
structurally incapable of adding gain. The stage that can add gain is a
leveler, off by default, capped at +5 dB, with a 500 ms decay.

piHPSDR wires the same split, and goes further:

SetTXAALCSt(tx->id, 1);            // turn it on (always on)
SetTXALevelerTop(tx->id, 5.0);
SetTXALevelerSt(tx->id, tx_leveler);

tx_leveler has three mentions in the whole tree — int tx_leveler=0;, an
extern declaration, and the read above. Nothing ever assigns it. So as
piHPSDR configures WDSP, the leveller is off and unreachable and the ALC cannot
amplify: there is no upward makeup anywhere in that transmit chain, and it
is a widely used client for this radio.

Where its operators get level instead is the microphone gain, which piHPSDR
ranges −12 dB to +50 dB. That pairing is the point: no automatic makeup, and
a wide manual control.

Hl2TxDsp has one stage that is always on, named ALC, and ceilinged at +40 dB
— the reference's two roles merged, keeping the always-on property of the
protective one and the gain range of the optional one.

The chain today, and proposed

today:     mic → AetherVoice strip (48 kHz, OFF by default) → 24 kHz
             → m_micGain (slider, NOT persisted)
             → "ALC": always on, up to +40 dB makeup, 500 ms release,
                      hold below −45 dBFS absolute
             → hard clamp → phasing modulator → EP2

proposed:  mic → AetherVoice strip (UNCHANGED) → 24 kHz
             → m_micGain (slider, PERSISTED)
             → LEVELLER: OFF by default, ceiling ~5 dB, operator-visible
             → ALC: always on, ceiling UNITY — protection only, cannot amplify
             → hard clamp → phasing modulator → EP2

Four changes, in dependency order

Each is a regression without the ones before it, which is why the order matters.

1. Persist the mic slider. The control already exists — registered as
phone.micLevel (a 0–100 slider under Phone/CW), MIDI-bindable as micgain,
and already reported in the health snapshot. It is simply not restored:
the mic-level setter in Hl2Backend.cpp says so itself, explaining why 50
must map to unity —
"TransmitModel constructs m_micLevel at 50 and nothing restores it at
startup". Any operating procedure that begins "set mic gain once" is defeated
by a control that resets to unity every launch, and every change below assumes
the operator's gain survives.

Note what that comment implies: the unrestored slider is not an oversight. The
code has already reasoned about the consequence and designed around it, pinning
50 to unity because nothing restores it. So this change asks you to remove a
constraint you documented, not to notice a bug you missed — and the mapping is
free to change once the value persists.

2. Give alcGain a meter. It currently drives none —
"alcGain drives no meter — TX:ALC is fed from alcPeak above" — and the gauge
labelled TX:ALC shows a post-ALC level, which Hl2TxDsp::processAudioBlock describes in
its own words as a meter that "sits pinned near the target by definition and
tells the operator nothing — it reports the ALC's success, not their input
level." Without this, changes 3 and 4 are invisible to the operator: they
would alter behaviour with no instrument showing what changed.

There is prior art here too. WDSP's transmit chain carries seven meters —
micmeter, eqmeter, lvlrmeter, cfcmeter, compmeter, alcmeter, outmeter
(the meter struct in TXA.h) — and its TXA_* readable enum exposes
TXA_LVLR_GAIN and TXA_ALC_GAIN as separate quantities. Keep the existing level gauge but name it for what it
shows, and let TX:ALC carry the gain quantity every other rig means by that
label.

3. alcMaxGainDb 40.0 → 0.0, together with a wider mic-gain range. The ALC
becomes what its name means, and what the reference's ALC is: protection only,
structurally unable to amplify.

These two must land together, and here is the arithmetic. The file puts
speech at −32 dBFS and alcTargetPeak at 0.85, which is −1.4 dBFS — a gap of
30.6 dB. The mic slider spans ±20 dB ("0.4 dB per slider step"). Remove the
makeup without widening that range and the chain is 10.6 dB short at maximum
slider: the symptom becomes "the radio went quiet and there is no control
left", which is the same fault as the original pointing the other way. piHPSDR,
which as shown above has no makeup at all, gives its operators −12 to +50 dB.

And the change is smaller than it looks. The whole content of the
clientLeveled special case is

const double ceiling = clientLeveled ? 1.0
                                     : std::pow(10.0, m_config.alcMaxGainDb / 20.0);

With alcMaxGainDb = 0 the ceiling is 1.0 on both branches. The branch, the
!clientLeveled term in the hold, and the entire one-sided TCI/DAX contract
stop doing anything and can be deleted. The fix removes more code than it
adds.

4. Add an optional leveller — off by default, ceiling ~5 dB, operator-visible
— to carry the makeup that change 3 removes, for operators whose microphone
genuinely needs it.

Why change 4 does not belong in AetherVoice

The strip is off by default. A leveller reachable only once an operator has
found and enabled an advanced panel is not a leveller, it is a feature. It has
to live in the always-on path, beside the ALC, which is where the reference puts
it.

One honest deviation: WDSP's order is expander → leveller → compressor, and
since AetherVoice holds both the expander and the compressor upstream, a
leveller placed in Hl2TxDsp lands after the compressor rather than before
it. That is a real difference from the reference and is named here rather than
left for a reviewer to find. It is a consequence of where the two chains meet,
not of the proposal.

On WDSP's TX chain — not what is being asked for

Hl2TxDsp's own header explains why this backend does not use TXA: driven from
this configuration a TXA channel "returned Underrun on most blocks and zeros on
the rest", two speculative fixes at the initialisation sequence made things
worse, and the deciding factor was that "the failure mode is SILENT" where a
fifty-line phasing modulator's correctness is measurable.

That reasoning is sound and this issue does not ask for it to be revisited.
The suggestion above changes one ceiling in the existing chain.

What this issue does not claim

• One operator, one voice, one capture device. The live figures are three
  passes from a single operator on AirPods. The loopback figures are authored to
  match a different, hotter arrangement. The two devices measured here behave
  differently — one crosses the threshold on transients, the other on its steady
  floor — and that difference is the point rather than a weakness, but neither is
  a survey.
• Measurement windows differ and are stated. Floor, output and contrast are
  tap-derived over the first 14.9 s of each pass; the gain trajectory covers the
  full 30 s. The pauses quoted above fall inside the tap window.
• Whether either capture device applies AGC is not established. The 30 s
  time-resolved silence measurement above is of the webcam microphone. The
  AirPods the operator transmits on were measured at rest too — 6 s at their
  native 24 kHz, peak −57.05 dBFS, RMS −80.10 dBFS — but as a single figure pair
  and not as a block series, so for that device flatness over time is not shown
  either way. And even for the device where it is, flatness rules out a
  winding AGC but not a holding one — an AGC may sit still on silence, exactly
  as the stage described here does below its own threshold. The level-step test
  that would settle it has not been run for either device. The argument above is
  deliberately built so that it does not depend on the answer.
• No claim that computer microphones in general level their audio. General
  sources say device-side AGC is common and often hard to disable; that is
  background, not evidence about any particular device, and the one device
  measured here does not appear to wind.
• No claim that other clients avoid this. Only that WDSP's leveller uses a
  relative, operator-visible threshold where this one is absolute and hidden.
  Whether other implementations enable their leveller by default is not
  established here.
• Scope is the HL2 backend. Flex and Icom modulate in the radio and never run
  this code. ANAN declares host modulation and would inherit the same decision
  when its transmit path lands.

[aethersdr-agent]

Triaged: maintainer-review. I checked every load-bearing claim in this report against the tree and they all hold, including the quotations. Below is the verification, then two corrections/additions to the proposed fix that change what change 3 has to touch.

Verified against the source

The mechanism, src/core/backends/hl2/Hl2TxDsp.cpp:234-279. Quoted exactly:

const double ceiling = clientLeveled
    ? 1.0
    : std::pow(10.0, m_config.alcMaxGainDb / 20.0);   // line 242-244
const double wanted = m_config.alcTargetPeak / blockPeak;
const double target = std::min(wanted, ceiling);
const bool reducing = target < m_alcGain;
const double holdThreshold = std::pow(10.0, m_config.alcHoldBelowDbfs / 20.0);
const bool held = !reducing && !clientLeveled && blockPeak < holdThreshold;  // line 265-266
if (!held) { /* one-pole toward target, tau = attack if reducing else release */ }

Hl2TxDsp.h:59-62,84: alcTargetPeak = 0.85, alcMaxGainDb = 40.0, alcReleaseSec = 0.500, alcHoldBelowDbfs = -45.0. Hl2TxDsp.h:55-56 is where "speech sits around -32 dBFS" comes from.

The one-way property is real and follows directly from that expression. Trace the reported pause: m_alcGain at 16.65 dB (6.8x), a transient block at −31.6 dBFS (0.0263) → wanted = 0.85/0.0263 ≈ 32x (+30.2 dB), below the 100x ceiling, so target = 32x. reducing is false, blockPeak is above holdThreshold, so held is false and the gain releases upward toward +30 dB. Every subsequent block of the pause sits at −65 dBFS, below the threshold, reducing false → held true → the gain is frozen at +30 dB for the rest of the pause. The 16.65 → 30.70 dB figure and the 0.00 dB contrast pinned at −1.41 dBFS (= 20·log10(0.85)) are exactly what this code produces. The hold does not undo, it only refuses to lift further; only a louder block makes reducing true, and a pause contains none. Confirmed, and the slider-90 control case — gain frozen to the second decimal — is the same expression with nothing crossing.

The second route is also real and is documented in the tree as intended behaviour. Hl2Backend.cpp:3885-3892 and Hl2TxLevelPolicy.h:50-58 both say the slider's purpose on the mic path is to carry a quiet mic over the hold threshold; micSliderToGainDb is (level − 50) · 0.4, i.e. ±20 dB. So raising gain to be heard is the same act that pushes a steady floor across the threshold. Same defect, same expression.

The reference-implementation claims check out verbatim. third_party/wdsp/upstream/TXA.c:158-180 — leveler run = 0, tau_decay 0.500, max_gain 1.778; TXA.c:313-335 — alc run = 1, tau_decay 0.010, max_gain 1.0. The always-on stage genuinely cannot amplify.

The meter claim checks out. Hl2Backend.cpp:546-561: TX:ALC is fed from alcPeak (a post-ALC level, pinned near target by construction); alcGain is stored into m_alcGainDb for the health snapshot and drives no meter.

The persistence claim checks out. TransmitModel.h:444 is int m_micLevel{50}; phone.micLevel is registered at MainWindow_Controllers.cpp:2025 and MIDI-bound at MidiSettings.cpp:110, and there is no AppSettings key for it anywhere in src/. Nothing restores it.

Not a duplicate; nothing else open covers this.

Two things the proposal understates

1. Under a unity ceiling the hold must be deleted outright, not just its !clientLeveled term. The issue says the branch and the !clientLeveled term "stop doing anything". The branch does — but the hold does not become inert, it becomes harmful on the mic path for precisely the reason Hl2TxDsp.cpp:255-262 gives for excluding the client path today. With alcMaxGainDb = 0, target = min(0.85/peak, 1.0), so after a loud block pulls m_alcGain below 1.0, a following quiet block has target = 1.0 > m_alcGain → reducing false, blockPeak below threshold → held true, and the gain is stranded at whatever reduction the loudest block called for. That is #4796 mirrored onto the mic path. So change 3 is: alcMaxGainDb → 0.0, delete the ceiling ternary, delete held/holdThreshold/alcHoldBelowDbfs entirely. hl2_txdsp_test.cpp:539-544 already documents this exact failure from the other side and its quiet leg is deliberately placed to catch it.

2. Change 3 has three more call sites than the diff in the issue suggests.

• Hl2Backend.cpp:39 — a static_assert pinning alcHoldBelowDbfs == -45.0.
• Hl2Backend.cpp:1962, 4343-4345 — m_alcHoldBelowDbfs is mirrored into the health snapshot.
• Hl2Backend.cpp:3267-3293 — the unkey "Raise mic gain" diagnostic fires on m_txMicPeakMaxDbfs < alcHoldBelowDbfs. With no makeup and no hold this advice is right for a different reason (there is no longer anything closing the 30.6 dB gap but the slider), so it should be re-pointed at the new mic-gain range rather than deleted — otherwise the one instrument telling a quiet operator what to do disappears in the same change that makes them quiet.

Existing tests that will need rewriting rather than adjusting: hl2_txdsp_test.cpp:292-345 (the hold case, which asserts the behaviour being removed) and hl2_tx_level_policy_test.cpp (the ±20 dB mapping).

Handoff

Root cause: one always-on stage in Hl2TxDsp::processAudioBlock merges WDSP's two distinct roles — it keeps the protective ALC's always-on property and the optional leveller's gain range, at 8× the leveller's ceiling. Its only defence against winding up on room noise is an absolute threshold on an instantaneous block peak, which cannot separate a breath from a syllable and, once crossed, has no path back down inside a pause.

Recommended shape: the four-step sequence as proposed, with the two amendments above. The order is genuinely load-bearing — 3 without 1 loses the operator's setting every launch, and 3 without the widened mic range leaves the chain 10.6 dB short at full slider.

What needs a maintainer decision rather than analysis: change 3 alters the on-air level of every existing HL2 install, so the mic-range widening and the persistence work have to ship in the same release, and the release notes have to say so. That is a product call, not a code one. Changes 1 and 2 (persist phone.micLevel; give alcGain its own meter and rename the existing gauge to what it shows) are independently correct, carry no on-air behaviour change, and could land first to de-risk the rest.

Scope: HL2 only. Flex and Icom modulate in the radio and never reach this code; ANAN would inherit the decision when its TX path lands.

The operator workaround in the report — enabling the client gate/expander ahead of the ALC to drop the floor back under the threshold — is sound and works for the reason given.

---

_{🤖 aethersdr-agent · cost: $2.0295 · model: claude-opus-5}

---

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

Unresolved citations (15)

Citation	Reason
Hl2Backend.cpp:1962	file not found in workspace
Hl2Backend.cpp:3267-3293	file not found in workspace
Hl2Backend.cpp:3885-3892	file not found in workspace
Hl2Backend.cpp:39	file not found in workspace
Hl2Backend.cpp:546-561	file not found in workspace
Hl2TxDsp.cpp:255-262	file not found in workspace
Hl2TxDsp.h:55-56	file not found in workspace
Hl2TxDsp.h:59-62	file not found in workspace
Hl2TxLevelPolicy.h:50-58	file not found in workspace
MainWindow_Controllers.cpp:2025	file not found in workspace
MidiSettings.cpp:110	file not found in workspace
TXA.c:313-335	file not found in workspace
TransmitModel.h:444	file not found in workspace
hl2_txdsp_test.cpp:292-345	file not found in workspace
hl2_txdsp_test.cpp:539-544	file not found in workspace

[on8st]

Correction to change 4, from the author.

The section "Why change 4 does not belong in AetherVoice" argues the leveller must sit in Hl2TxDsp because the AetherVoice strip "ships off by default". I checked that premise afterwards and it does not hold as stated: the strip is not a gate.

AudioEngine calls m_txVoiceProcessor->processCapturedFloat32() / processCapturedInt16() unconditionally on every captured mic block, and inside TxVoiceProcessor::processWorkBuffer each stage is gated only by its own isEnabled() — m_processors.eq->isEnabled(), comp->isEnabled(), gate->isEnabled(), and so on. There is no master switch. So a leveller added to the strip costs the operator one toggle, exactly as many as a leveller added to Hl2TxDsp, and the distinction I drew between "a leveller" and "a feature" has no counterpart in the signal path.

With that premise gone, change 4 is better placed inside AetherVoice, before the compressor, for three reasons:

1. It keeps the reference's order. xtxa runs xwcpagc(leveler) before the compressor and fixes that order rather than exposing it. A compressor's threshold is absolute, so it only means anything if the average reaching it is already controlled — which is precisely the leveller's job.

2. It keeps the client path clean for free, and this is the one that matters for change 3. TCI/DAX bypasses the strip: AudioEngine's own comment is that the path carries "pre-shaped digital tones from TCI/DAX, so no compressor, EQ, Quindar or brickwall limiter runs on it". A leveller in the strip therefore never sees client-levelled audio. A leveller in Hl2TxDsp sits squarely in that path and would need its own bypass — which is the clientLeveled branch change 3 deletes, re-created one stage later. Putting the leveller in the strip is what lets change 3 stay a deletion.

3. It reuses a shape already in the tree. A ClientLeveler in the mould of ClientComp / ClientFinalLimiter is one new file pair against an existing pattern, with the settings-key and meter conventions that come with it. Hl2TxDsp has none of that shape.

This also removes the "one honest deviation" the issue named: with the leveller in the strip it lands before the compressor, as in the reference, rather than after it.

What survives from my original argument is discoverability, which is a UI question rather than a signal-path one — an operator hunting for level looks at the Phone/CW panel, not at an advanced strip editor. That is answered by surfacing the control there while the processing lives in the strip. I conflated the two.

Changes 1, 2 and 3 are unaffected.

[on8st]

Thank you for the triage — I checked every one of its claims against my own tree and all three "extra call sites" confirm by symbol. Reporting back with three places it undercounts and two refinements, because the difference changes what change 3 has to touch.

First, a note on your citation checker. Its footer reports 15 unresolved citations as "file not found in workspace". All 15 resolve here. Whatever it was pointed at, it was not the tree the analysis was done against — the citations themselves were good.

Where the count is short

The call sites are at least six, not three. Beyond the static_assert, the two snapshot sites and the diagnostic, these also assert the mechanism being deleted:

• the Hl2TxDsp::micPeak connect comment in Hl2Backend's constructor
• both halves of Hl2Backend::setMicGain's doc comment
• Hl2TxLevelPolicy.h's micSliderToLinear comment

And the snapshot's txMicPeakDbfs row names the row being deleted as its companion — "these two rows are the whole 'why did I go out quiet' diagnosis" — so deleting one strands a documented pair.

A third test needs rewriting, not two. hl2_txdsp_test.cpp's "ALC lifts speech-level audio to something that modulates" asserts "ALC lifts quiet audio substantially" and "ALC brings quiet audio near full modulation". Both fail outright under a unity ceiling. It is the case that encodes the purpose being reversed, so it is the one most worth deciding about deliberately.

And one that fails silently. constexpr double kSlider100 = 10.0; // micSliderToLinear(100) = +20 dB appears twice in hl2_txdsp_test.cpp. After the widening the name and the comment are both wrong while the arithmetic still passes — nothing goes red.

Two refinements

alcTargetPeak is not mirrored into Hl2Backend and is absent from healthSnapshot(). So deleting alcHoldBelowDbfs entirely leaves the diagnostic and the snapshot with nothing to compare against. Substituting the mirror — and re-pointing the static_assert at alcTargetPeak == 0.85 — is a smaller change than the deletion.

Your re-pointing recommendation is right, and stops one step short. The reason you give is the right one: the single instrument telling a quiet operator what to do would vanish in the change that makes them quiet. But at slider 100 with the peak still low, "raise mic gain" becomes wrong advice — and this change is what first makes that state reachable, since it is the 10.6-dB-short case. The re-pointed diagnostic has to read m_micLevel and say something different at the top of travel. I have not proposed the new margin; that is the bench's to set, not mine to invent.

Also, in your favour

On hl2_tx_level_policy_test.cpp — "the ±20 dB mapping" reads as the whole file, but under an asymmetric widening only three of nine mic assertions change. The below-50 leg is untouched and its assertions survive verbatim.

And we reached the hold-deletion trap independently, by different routes — mine from the source comment ("under a unity ceiling there is no makeup gain to chase with, and holding would be actively harmful"), yours from the expression. Yours is the better statement of it, because naming the limiter-release case makes it testable rather than only derivable.

One practical note. Your Hl2Backend.cpp citations run consistently ahead of mine (+3, +44, +163, +166, +312 in file order) while every other file lands within two lines. That suggests main is roughly 300 lines ahead of my checkout on that file specifically — which is where most of the newly found sites live. I will rebase before offering anything.

[on8st]

The four-PR series is implemented and measured on a bench. Reporting back two
things: what the numbers say, and three places where this issue's own change
spec is wrong — each found by implementing it rather than by reading it.

Everything below keyed a SIMULATOR. The peer is hpsdrsim answering as
AA:BB:CC:DD:88:FF. No RF was radiated, nothing reached an antenna, no spot went
to WSPRnet. The approval was a loopback approval issued by this lab's own
orchestrator, not by the operator. That is sound for this stage and only this
stage: Hl2TxDsp is host-side DSP and runs on m_keyed regardless of peer, so
the code under test executes identically — and the run says nothing whatever
about anything downstream of the wire.

Builds: stock is the binary that matched its BUILD.json at 63a4a2e9; the
fixed build is PR 1 + PR 2 + PR 3 merged, 98c4d2c9.

---

Part 1 — the bench

A. Ten silent overs, mic slider swept

Thirty seconds keyed per leg, ten legs, sliders 50…100 in an order shuffled
under a fixed seed so room drift shows as scatter rather than as a slider trend.
Same room, same USB microphone (Logitech 4K Stream Edition).

Stock, peak alcGain reached inside a single silent over:

slider	50	60	65	70	70 (rpt)	72	75	80	90	100
max gain (dB)	0.00	19.18	30.98	30.88	31.40	38.74	39.66	39.85	39.97	37.52

Fixed build: 0.00 dB on every one of the ten legs. It never lifted. It did
reduce where the drive called for it — the last sample reads −5.28 dB at slider
100 and −1.39 dB at slider 65 — which is the stage doing what its name means.

The control that matters here, stated because it cuts against a naive
reading. These two runs are not a like-for-like input comparison and must not
be shown as one. PR 3 widens the mic slider from ±20 dB to ±40 dB, so an
identical slider position delivers a hotter signal on the fixed build. At
slider 100 the pre-ALC peak txMicPeakDbfs goes from −25.96 dBFS stock to
+35.48 dBFS fixed. The fixed build was fed roughly 20 dB more and still applied
zero makeup. The comparison is only fair in that direction, and that is the
direction that favours the change, so it is worth being explicit that the reverse
comparison was never available.

A falsifier fired, and it was ours. The run declared the claim "within one
over the ALC gain can only rise; it ratchets on the loudest transient and resets
only at key-off", with the falsifier "any downward movement of alcGainDb
during a silent over". It moved down: 148 downward steps across the ten stock
legs, almost all of them in the two hottest (slider 90: 153 up / 56 down;
slider 100: 162 up / 89 down). So the strict "can only rise within an over"
reading is refuted by this bench and I will not repeat it. What survives is
what the report and your triage already said, and it is enough: reduction is
never held, so a loud block does pull the gain back — the fault is the level
during a pause, not a level that runs away across the over.

And an honest weakness. Nine of the ten stock legs and nine of ten fixed legs
carry the runner's own room-event flag: "a transient N dB above this leg's own
p99 — the room was not quiet for this leg." These were meant to be silent overs
and they were not perfectly silent. That is not fatal — what an imperfectly
silent room does to this stage is precisely the complaint — but they are not the
clean silence they were designed to be, and someone re-running this should expect
to fight for a quieter room than I got.

B. Speech and pauses — the like-for-like pair

Same authored stimulus on both builds (sp-38.wav, sha256 59de8341…), client
gate off, mic slider 50 = unity (0 dB) on both builds, so this pair has no
mic-range confound at all.

The delivered floor at the ALC is the same to within 0.02 dB:

	stock	fixed
floor at ALC, p50	−42.05 dBFS	−42.05 dBFS
floor at ALC, max	−38.74 dBFS	−38.76 dBFS
blocks above the −45 dBFS hold threshold	100 %	100 %
pre-ALC txMicPeakDbfs	−20.64 dBFS	−20.64 dBFS

On that identical floor:

pause	stock contrast	stock pause level	fixed contrast	fixed pause level
1	0.21 dB	−1.39 dBFS	18.10 dB	−39.18 dBFS
2	0.20 dB	−1.38 dBFS	17.96 dB	−39.04 dBFS

−1.39 dBFS is alcTargetPeak 0.85 exactly, as the report predicted. The gain
trajectory inside each stock pause runs 19.92 → 38.97 dB, 19.72 → 38.56 dB, and
(from the uncapped health trajectory, past the 15 s tap cap) 19.42 → 39.53,
19.91 → 39.33, 20.00 → 39.43. On the fixed build every one of those five reads
0 → 0.

The cost, named rather than buried: speech went from −1.18 dBFS to
−21.08 dBFS. At unity mic gain the fixed build transmits about 20 dB quieter.
That is not a surprise, it is the 30.6 dB gap the report's own arithmetic
predicted, and it is exactly why change 3 cannot ship without the widened mic
range and change 1's persistence. An operator who upgrades into this without
setting their gain goes out quiet.

The below-threshold control leg is more interesting than expected. With the
floor at −50 dBFS — under the hold threshold, the case where the hold works —
stock still only managed 22.85 / 23.27 dB of contrast with the gain climbing
19.98 → 27.02 dB, against the fixed build's 30.25 / 30.06 dB flat at 0 dB. So
even in the non-fault condition roughly 7 dB of contrast is lost to makeup
applied before the hold engages.

Two things this pair does NOT establish, from the run's own record:

• client_leveled_false_proven: false — on the fixed build the gain never
  exceeded 0 dB, so a clientLeveled = true over and a correctly-held over are
  indistinguishable in these figures. The run cannot tell them apart.
• The two operator-shaped legs in the same run are not comparable leg-to-leg
  with the original, and the result file says so in its own caveat field: they
  run at mic level 100, which is +40 dB on this build and was +20 dB on the
  original — 20 dB hotter. What they do show, on the fixed build alone, is the
  stage working in the direction its name means: gain at pause start −6.09 /
  −8.52 / −8.31 / −1.85 / −8.32 dB, returning to −0.003 dB by pause end. It only
  ever cuts.

C. A real WSPR beacon, three binaries

Six legs. One real WSPR frame each, generated by WsprBeacon and pumped through
AudioEngine::feedDaxTxAudioInternal, driven by the app's own
PskReporterMapDialog beacon button. No stand-in stimulus; nothing played
through an audio device.

leg	build	slider	beacon level	pre-ALC peak	post-ALC peak
stock-default	stock	50	−20 dBFS	−20.002 dBFS	−1.412 dBFS
alc-only-default	fixed	50	−20 dBFS	−20.002 dBFS	−20.002 dBFS
alc-only-micslider	fixed	100	−20 dBFS	+19.998 dBFS	−1.412 dBFS

Read the first two rows together: the stock stage applied +18.6 dB of makeup to
a machine-generated constant-envelope tone that was already at the level its
generator chose. The fixed build left it alone to within 0.000 dB.

Read the first and third rows together — this is the two-sided test. They
land on the same number, −1.412 dBFS, from opposite directions: stock reached
it by adding 18.6 dB, and the fixed build reached it by removing 21.4 dB from
a deliberately over-driven input. The stage still limits. It has stopped
amplifying. That is the whole of change 3 in two rows.

Controls. The pre-ALC peak across the three legs sharing beacon level
−20 dBFS and slider 50 has a spread of 0.0 dB (−20.002120971679688,
identically), so the post-ALC differences are attributable to the binaries and
not to the stimulus. And a same-binary default-vs-forced pair pins the one other
variable: on the third binary, the default leg reads −3.0 dBFS and a leg forced
to −20 dBFS reads −20.002, so that −3 dBFS comes from a changed default rather
than from the build. (That third binary carries a further change about
engine-generated audio which is a separate concern from this issue; it is here
only as the control that makes these rows readable.)

What could not be measured here. The txraw tap returned nothing on every
leg, by construction rather than by fault: it lives on the microphone path in
AudioEngine::onTxAudioReady, and AudioEngine::startWsprPump calls
setDaxTxMode(true), so a real beacon is invisible to it. The pre-ALC control is
therefore the health row txMicPeakDbfs — a per-over peak, not a captured
waveform, so it is sound for "were the legs fed the same level" and silent on the
input's crest factor. Nothing about the frame's timing, DT or symbol pacing was
measured. The capture is 15 s of a 111.6 s frame, in the constant-envelope
middle, because AudioEngine bounds an automation capture — the frame's ends and
tapers are unmeasured.

---

Part 2 — three corrections to this issue's change spec

Each of these was found by implementing the series, and each would have cost a
reviewer time or shipped a defect.

1. alcTargetPeak DOES occur outside Hl2TxDsp. The series asserts "checked,
no occurrence of alcTargetPeak outside Hl2TxDsp". That is false on main:
Hl2Backend::gatherDspChains publishes it as a DSP read-back field
(e["alcTargetPeak"] = t.alcTargetPeak), and hl2_dsp_readback_test asserts on
it. Anyone changing that constant on the strength of the spec's sentence would
miss a published field and a test.

2. m_swAlcIdx no longer exists, and neither does m_swAlcUnit. The series
tells an implementer to follow m_swAlcIdx's pattern — "index and unit captured
in the same place". Upstream f39e7d27 replaced the single index with the
per-TX-source / per-slice maps m_swAlcIdxByTxSource and m_swAlcIdxBySlice in
MeterModel, routed through registerTxWaveformMeter, and deleted
m_swAlcUnit outright — the string appears nowhere in src/. A new meter
following the spec's pattern would be written against a shape that is gone.

3. The change list omits Hl2Backend::defineMeters(), and the omission ships a
dead meter. defineMeters() on main runs from index 1 to 8 and stops at
TX:COMPPEAK; there is no ALCGAIN row. Without adding one, emit meterUpdate("TX:ALCGAIN", …) is a silent no-op: RadioModel's handler
splits the id and calls MeterModel::updateValueByName, which does
findMeter(source, name, sourceIndex), gets < 0, and returns false — and the
lambda discards that bool. The build is green, ctest is green, and the gauge
never moves. This is the same failure class as the one the file's own comment
records for IRadioBackend::meterUpdate having had no consumer at all, where
"the HL2 S-meter was correct for a while before anyone noticed it never reached
the UI".

Correction 3 is the one worth fixing in the issue text before anyone starts:
1 and 2 cost a reader some confusion, but 3 is a defect that passes every gate.

---

The branches

Four branches exist locally, one per PR, each rebased onto current main
(4722e910) with a clean merge base, plus an integration branch that carries the
four merges and three GUI fixes found by capturing the resulting gauges and
looking at them. They are unpushed and I am not going to push them. This
issue is under maintainer-review and CONTRIBUTING.md asks for one issue per
PR, so opening four PRs against a spec still being decided is the wrong move.

They are offered, not proposed. If you want any of them — and changes 1 and 2 are
the ones your own triage called independently correct with no on-air behaviour
change — say which and I will open them one at a time against whatever the spec
says at that point.

The bench findings above are reported on their own account regardless of what
happens to the branches.

[on8st]

Following up on my last comment, where I said the four branches were "offered, not proposed" and that I would open them one at a time if you said which. Changes 1 and 2 are now open as #5505 and #5506 — the two your triage called independently correct with no on-air behaviour change.

Changes 3 and 4 are ready and I am still not opening them unbidden. Asking rather than pushing, because there are three things that should shape your answer and one of them is a decision I cannot make from here.

1. What an operator feels, measured

The unity ceiling removes up to 40 dB of upward makeup that shipping builds apply today. On this station, at the default mic slider of 50, speech goes from −1.18 dBFS to −21.08 dBFS — about 20 dB quieter for someone who upgrades and changes nothing. The remedy is to raise the slider; about 74 put peaks back on target here.

That is a release note, not a footnote, and it is the reason I have been sitting on these rather than filing them.

2. This change breaks one of your own documents

docs/radio-certification.md's TX:ALC row expects "sweep the input 20 dB → reading does not move, ±1 dB", with recorded evidence of −1.41 dBFS at −10, −20 and −30 dBFS input.

That no-movement is the makeup's signature. After the unity ceiling, a correctly behaving radio fails that row. The row needs a new expectation, and the honest version of it is empirical — it needs measuring rather than reasoning, so I have deliberately not guessed one. Flagging it because a reviewer finding this after merge is much worse than reading it here.

3. A stacking question that is genuinely yours

hl2/alc-unity-ceiling does not contain hl2/alc-gain-meter — I checked with git merge-base --is-ancestor, and it builds and passes against bare main. But the meter it must correct exists only on #5506: Hl2Backend::defineMeters declares TX:ALCGAIN as -20.0, 40.0 under a comment citing Hl2TxDsp::Config::alcMaxGainDb, the field change 3 deletes.

So if #5506 merges and then change 3 merges as an independent PR against main, you get a meter declared −20…+40 over an ALC that can never exceed 0 dB. The rescale, and the gauge's fill direction that goes with it, currently live only on my integration branch.

Two ways to fix that, and I would rather you picked:

• Stack them — change 3 based on feat(meters): publish TX:ALCGAIN, the gain the HL2 ALC is applying (meter only — gauge in #5636) #5506, change 4 based on change 3 (that dependency is hard: change 4's thesis is that clientLeveled went vestigial under the unity ceiling, and it edits lines change 3 writes). Draft PRs naming feat(meters): publish TX:ALCGAIN, the gain the HL2 ALC is applying (meter only — gauge in #5636) #5506, rebased and force-pushed to my own drafts after feat(meters): publish TX:ALCGAIN, the gain the HL2 ALC is applying (meter only — gauge in #5636) #5506 squash-merges. The correction arrives as a diff.
• Independent PRs against main, with the meter change described in the body for you to apply. Fewer moving parts, but it relies on transcription.

One thing I would split out either way

Change 4 as it stands also carries an unrelated level change — the WSPR default from −20 to −3 dBFS in PskReporterMapDialog.cpp. Measured and defensible, but it does not belong bundled with an enum refactor, and I will separate it unless you would rather see it together.

---

Both branches are rebased on main at 52c1ced5, clean, commits signed, subjects under 72 characters ending Principle VIII. Full ctest 363/363 and 364/364. Say the word — including "not yet", which is a perfectly good answer while the spec is still being decided.

🤖 Generated with Claude Code

https://claude.ai/code/session_014TtnKQu6QGrSeBirGeAsAs

[on8st]

Following up on the certification-table point I raised earlier in this thread:
I said the replacement expectation for TX:ALC had to be empirical rather
than reasoned, and that I would not guess it. Here is the measurement.

The problem, restated. docs/radio-certification.md's Transmit table says
of TX:ALC: "sweep the input 20 dB → reading does not move, ±1 dB across the
sweep", with recorded evidence of −1.41 dBFS at −10, −20 and −30 dBFS of
injected tone. That no-movement is the observable signature of the ALC's 40 dB
of upward makeup — −1.41 dBFS is exactly 20·log10(alcTargetPeak) for the
shipped 0.85, and a stage with 40 dB of makeup drags any input from about
−41 dBFS upward onto that target. Making the stage reduction-only removes the
mechanism, so after this series lands the row would fail a correctly
behaving radio. The row is yours, from 76a52403; it is our change that
invalidates it, so the fix belongs in this series.

Method. Two builds out of one build directory with identical configure
arguments, differing by the ALC commit and by one constant in an unrelated
diagnostic string. Leg A is origin/main itself. Stimulus: the app's own
1 kHz host test tone via testtone, the same one
RadioCertification::stageDspLiveness uses and the same one the 2026-08-10
evidence used. Mic slider at 50 (unity on both builds — the one point where
the two mappings agree), speech processor off, TX:COMPPEAK 0.00 dB at every
level. Instrument: the published meter model through the automation bridge,
i.e. the meters a certification run actually reads. Drive register 0 into a
dummy load, so the transmit DSP runs and the PA emits nothing.

The control matters here more than usual. The test tone is injected at the
head of TxVoiceProcessor::processWorkBuffer and then passes through the
channel strip, mic gain, Quindar and the final limiter before it reaches
Hl2TxDsp. A stimulus flattened by any of those would produce a flat
TX:ALC that looks exactly like the answer. So TX:MICPEAK — measured
inside Hl2TxDsp, after the mic gain and before the ALC — is what proves the
input varied. It tracked the requested level to within 0.108 dB (mean 0.004,
sd 0.034) on both builds.

Leg A, on origin/main: your row reproduces. Settled TX:ALC at the
three documented levels reads −1.4181 / −1.4347 / −1.4349 dBFS — a spread
of 0.017 dB where the row allows 1 dB, and within 0.023 dB of the documented
−1.41. Over a wider sweep it holds from −40.97 to −0.97 dBFS of input with a
total span of 0.023 dB. Nine days after your figures were taken, on the
same radio, they are exact. That is what earns the right to publish the
second leg.

Leg B, with the unity ceiling: the row fails by 28.6 dB, and what replaces
it is a straight line.

TX:MICPEAK (input)	TX:ALC	difference
−54.892	−54.892	0.000
−40.018	−40.018	0.000
−29.993	−29.993	0.000
−19.995	−19.995	0.000
−9.993	−9.993	0.000
−2.594	−2.593	+0.001
−1.406	−1.424	−0.018
−1.112	−1.412	+0.300
−0.971	−1.413	−0.442

Over 18 levels spanning 53.5 dB, TX:ALC − TX:MICPEAK never exceeds
0.0065 dB (mean −0.0005, sd 0.0015) and the fitted slope is 0.99997.
Above the target the reading limits at −1.4136 … −1.4125 dBFS, within
0.002 dB of 20·log10(0.85). The knee was located rather than assumed: still
tracking at an input of −1.406 dBFS, already at the target at −1.112 dBFS.
Approaching a level from above versus from below changes the reading by
0.0 dB.

The row I would propose, if you want it:

| `TX:ALC` | dBFS | **host-side** | post-ALC transmit peak | sweep the input 20 dB **below** the ALC target → reading **tracks the input 1:1** | **within ±0.25 dB of `TX:MICPEAK` at every level** |
| `TX:ALC` at the limit | dBFS | **host-side** | the ALC's target | raise the input **above** the target → reading stops at `20·log10(alcTargetPeak)` | **−1.41 dBFS ±0.25 dB** |

On the ±0.25 dB, because it is the part most worth arguing about: it is
margin, not measurement. The measurement is 0.0065 dB worst-case and
0.0015 dB sd, and ±0.05 would be supported by every number I have. I am
proposing something 40× looser deliberately, because I have one radio, one
host and one night, and a certification row that only passes on the machine it
was measured on is worse than a loose one. If you would rather have the tight
number and treat a failure as a real signal, the data supports that and I have
no objection.

Two things about running this row that the old one did not say, and that
cost me time:

• It cannot be certified without transmitting.
  Hl2Backend::submitTxAudio returns early unless m_keyed, so both meters
  are dead in a receive-only session. A load and a keyed window are needed.
  Drive can be zero — the quantity is host-side — which is how this was run.
• Let it settle. On the reduction-only build the reading is settled within
  one meter update. On origin/main it is not: after a step down in level the
  makeup climbs on a 0.5 s release constant, and a reading averaged across the
  first half of a 3 s dwell sits up to 0.78 dB away from the settled one —
  most of the old row's ±1 dB budget spent on the instrument rather than the
  radio.

One more thing worth recording, which is about the old row rather than the
new one. The current expectation does not hold over the whole input range
even on origin/main. Below about −42 dBFS the makeup's 40 dB ceiling binds
and the reading starts tracking again (TX:ALC − TX:MICPEAK = +39.99 to
+40.00 dB, i.e. alcMaxGainDb exactly); at −42.96 dBFS the reading is already
1.55 dB off target, outside the row's own ±1 dB. And below the −45 dBFS hold
threshold it becomes path-dependent: I measured the same stage at
comparable inputs reading +33.17 dB and +39.996 dB of applied gain depending
only on how the level was approached. So the row as written is not merely
stale — outside a band it never stated, it has no single value to be right
about. That is an argument for the reduction-only change rather than against
the old row's authors.

What I did not measure, since it bears on how much weight to put on the
above: anything radiated (drive was zero throughout); anything below
−54.9 dBFS of input (the host tone clamps at −60 dBFS) or above about −1 dBFS
(the tone saturates there, so the limiting clause rests on three points); any
radio but this one; and TX:ALCGAIN, whose meter does not exist on either
build I ran. Raw data, both builds' SHAs and the per-sample record are on the
bench and I can attach whatever is useful.

🤖 Generated with Claude Code

https://claude.ai/code/session_014TtnKQu6QGrSeBirGeAsAs

[on8st]

Correcting myself on one point above, before it costs anyone a merge.

Earlier in this thread I offered to split the WSPR/digital default change out of change 4, and described it as an unrelated one-line change that could be taken independently. It is neither of those things, and the second half matters.

It is not one line. It is backend-conditional: hostModulates ? -3 : -20 in PskReporterMapDialog.cpp, keyed off AudioEngine::hostModulation(), so Flex and Icom keep −20 and only host-modulating radios move.

And it is a no-op on main today. Hl2TxDsp::processAudioBlock() still applies the makeup half of the ALC to audio arriving with clientLeveled = false, and AudioEngine::startWsprPump() reaches feedDaxTxAudioInternal() without marking an external source — so −20 and −3 dBFS both transmit at −1.412 dBFS, which is 20·log10(alcTargetPeak) for the shipped 0.85. alcEnabled defaults true and has no UI, so there is no reachable configuration in which the two differ.

Landed in the wrong order it is a silent 18.577 dB shortfall. Measured on this bench, same −20.000 dBFS stimulus, two builds one change apart: stock reads −1.412 dBFS, ALC-unity reads −19.989 dBFS. The txraw control spread across the pair is +0.000 dB, which is what makes the difference attributable to the change rather than to the run.

So: the WSPR default must not land before the unity ceiling. With the ceiling, −3 dBFS is what puts WSPR back on target; without it, the constant does nothing and then does something the day the ceiling merges. I have separated it onto its own branch with that sequencing written into the commit body, and it stays unpushed with the rest of the series pending your answer on the questions above.

Flagging it because I told you it was independent, and a reviewer taking it at its word would have found out at merge time instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_014TtnKQu6QGrSeBirGeAsAs