[on8st]

Closes #6004.

The defect is TX audio reaching Hl2TxDsp::modulate() in bursts of two or more 512-sample blocks. The stage always runs at the fixed 24 kHz transport rate (TxVoiceProcessor::kTransportRate), whatever the device rate. modulate() exchanged the blocks of a burst back-to-back with the non-blocking TXA channel. The second underran, fexchange2 advanced its read index anyway, and WDSP's two-slot output ring was then read out of step, splicing every later block boundary. modulatorFaultBlocks only counted the first underrun.

Known routes to a burst:

• macOS: Qt's QAudioSource delivers 1024 frames per flush regardless of the device rate. At 24 kHz (Bluetooth headset mics such as AirPods Max) that is two blocks per delivery, and at 16 kHz three.
• Linux/Windows pull path: TxCaptureBuffer returns everything available on each read, so any read of 2048 or more frames at 48 kHz reaches modulate() as two blocks. VE3LPR saw the underrun that starts the splicing with a 48 kHz input on Linux ([bug] Hermes-Lite 2 v26.8.4 — Transmitted USB/LSB audio distorted; ALC meter swings full range despite controlled AetherVOICE levels (HL2) #5198, HL2: TX audio spliced when it reaches the modulator in bursts (macOS 24/16 kHz mics, Linux 48 kHz) #6004).
• Queued thread hops (AudioEngine thread → GUI thread → I/O thread): if either thread is busy, consecutive deliveries run back-to-back on the I/O thread, which has the same effect.

Fix

• Hl2TxDsp queues levelled audio and exchanges a block only when WdspChannel::outputReady() reports the previous output is ready. It retries from a 1 ms timer on its own thread, so nothing blocks the I/O thread. A head block whose worker has not answered within one block period of becoming due is dropped, not exchanged (an exchange would desync the ring), and counted in modulatorFaultBlocks() and modulatorStallDrops(). Queue depth above four blocks is warned once per excursion. Every over starts with an empty queue and a fresh deadline.
• WDSP local patch 15 adds GetChannelOutputReady() and makes dexchange() publish a block into r2_havesamps only after copying it. The reorder applies to every channel; AETHERSDR-PATCHES.md documents its effect on RX (no latency change; the count becomes visible one memcpy later). It is numbered 15 because fix(wdsp): free the minimum-phase design workspace after each design, and disclose #5954's costs. Principle VIII. #5965 claims 14.

Evidence

Measured on hpsdrsim with a 24 kHz input:

	before	after
tone phase breaks (5.5 s)	252	2 (start and end)
speech envelope dips/s	3.58	0.0 (48 kHz baseline on macOS/hpsdrsim 0.13)

Verified by ear with a real AirPods Max microphone, on the simulator (before: chopped, after: clean) and on the air through a real HL2 by the operator.

Tests

New hl2_txdsp_capture_burst_test: a 1 kHz tone delivered as 48, 44.1, 24 and 16 kHz devices group it, plus two seam-driven stall cases (deadline from due, drop not exchange; fresh deadline per over). On main the 24 kHz case reports 1 fault and ~120 splices in 2 s; with the fix all cases pass. A rate case whose worker is stalled by machine load exits 77 (skipped); an underrun always fails. It does not pin the dexchange() reorder, which rests on the argument and measurement in the patch doc.

Not in this PR

A single 64–88 ms gap can occur right after key-up because the outgoing sample queue starts empty. It also happens at 48 kHz and on main. It will be a separate change, since the fix (a short pre-roll) changes transmit timing.

🤖 Generated with Claude Code

[aethersdr-agent]

Thanks for this one, @on8st — a two-slot ring being read out of step for the rest of an over, with the fault counter reporting 2 out of ~250, is exactly the kind of near-silent defect that's miserable to find. The 252 → 2 phase-break measurement and the "before: chopped, after: clean" A/B on hpsdrsim are the right shape of evidence, and numbering the WDSP patch 15 with the reason written down in AETHERSDR-PATCHES.md is appreciated.

What failed

da570c2a — check-windows, failing step Build (run 36425856547).

Everything else on that commit was either green or still running:

Check	Result
check-windows	failure — Build
build (Linux)	in progress at time of writing
check-macos	in progress at time of writing
Static checks	success
Sanitizer option configures	success

Being straight with you about one limit: the CI tooling I have returns per-step status only, not the compiler output, so I'm not going to quote you an error line I haven't actually read. Please open the Build step log and search for the first error C — MSVC's first error is the real one and the rest are usually cascade. If you paste it here I'll narrow this down properly.

What I can do is tell you where to look. All eight files in the diff are portable on inspection — no windows.h, no std::min/std::max near it, <algorithm> is present in Hl2TxDsp.cpp, and the patch-15 declaration in third_party/wdsp/include/aether_wdsp.h is correctly inside the extern "C" block, so it isn't a C++-mangling link failure. That leaves a short list, cheapest first:

1. M_PI in the new test. tests/hl2_txdsp_capture_burst_test.cpp:111 and :172 use M_PI, and MSVC's <cmath> doesn't define it without _USE_MATH_DEFINES set before the include. This is the repo's single most frequent Windows-only compile break (#4337, #2732 — and CHANGELOG.md:7413 records the same thing for M_PI_2).

Caveat worth stating: tests/hl2_txdsp_test.cpp uses M_PI with almost the same include set and is green on Windows, so M_PI is evidently arriving there via a Qt header. Your TU's include set differs (<QElapsedTimer>, <QEventLoop>), so it's plausible it no longer does — but it's not certain, which is why it's a "check this first", not a diagnosis. The repo's three established fixes, any of which is fine:

• a file-local static constexpr double kPi = 3.14159265358979323846; — tests/hl2_cw_bfo_test.cpp:50
• #include <numbers> and std::numbers::pi — src/core/WfmDsp.cpp:7, tests/wfm_dsp_test.cpp:16
• #define _USE_MATH_DEFINES before the includes — tests/asr_segmenter_test.cpp:6-9

2. std::size_t without <cstddef>. The new test uses std::size_t in struct Result and in run(), but doesn't include <cstddef>. It leaks in from <vector>/<string> on libstdc++ and libc++; MSVC's STL is stricter about what it re-exports. One-line fix, and worth adding regardless.

3. The PORT asymmetry on patch 15 — lower probability, but it is the one thing in the diff that is genuinely MSVC-shaped. PORT is __declspec(dllexport) (third_party/wdsp/upstream/comm.h:141). Your definition in iobuffs.c carries PORT, but neither declaration does — third_party/wdsp/upstream/iobuffs.h:99 and aether_wdsp.h:45 are both bare, whereas every other exported entry point in iobuffs.h (fexchange0, fexchange2) carries PORT. Harmless for a static lib; if WDSP is a DLL in the Windows build it's exactly the class of thing that compiles everywhere and only bites on MSVC. Matching the fexchange2 pattern costs nothing and removes the question.

Not a CI infrastructure failure

Worth ruling out explicitly, since that's the other common answer: all the fragile setup steps (Restore Qt, FFTW3, DeepFilterNet3, sccache, MSVC env, hidapi, PortAudio) succeeded, Configure succeeded, Build Opus succeeded, and both GPU/PortAudio enablement assertions passed. The failure is squarely at compile/link of the tree. No reviewer or Copilot comments have been posted on the PR yet, so there's nothing from that side pointing at a related code issue.

One thing to watch once it builds

Not a build problem, so separate from the above: m_exchangeTimer->start(1) with Qt::PreciseTimer (Hl2TxDsp.cpp:339, :347). You picked PreciseTimer, which is the right call — Windows' default timer resolution is ~15.6 ms and a CoarseTimer retry would have been far slower than a block period there, quietly turning your bounded stall path into the common path. Since check-windows died before hl2_txdsp_capture_burst_test could run, Windows hasn't yet exercised the 24 kHz burst case at all. It'd be worth confirming the fault count is still zero there once the build is green, because the fallback timing is the part of this design most likely to behave differently per-platform.

Docs, for reference: AETHERSDR-PATCHES.md · docs/architecture/audio-pipeline.md

Very likely a one-line portability fix on a genuinely good change. Drop the first error C line in here and I'll confirm it.

---

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

[aethersdr-agent]

Issue fit

Yes, for the mechanism it names. #6004's cause section and this diff line up exactly: modulate() exchanged every block a delivery carried back-to-back against a bfo = 0 channel, the second call took fexchange2's *error += -2 branch, and that branch advances r2_outidx without consuming (third_party/wdsp/upstream/iobuffs.c:645) so the two-slot ring (r2_active_buffsize = DSP_MULT * r2_size, iobuffs.c:406) is read out of step for the rest of the over. The gate + patch 15 is the right shape of fix, and the reorder in dexchange() genuinely is required by it rather than decoration — I traced r2_havesamps and confirmed upstream publishes the count at iobuffs.c:711 before the data was in r2, which only matters to a host that exchanges the instant the count says ready.

Two requirements from the issue are not covered: 44.1 kHz (18 splices in the issue's own table, the second-worst rate) is not exercised by the new test, and the 6 splices the issue measured at 48 kHz have no explanation in this diff — the new control case asserts splices == 0 at 48 kHz, which is in tension with the issue's own 48 kHz row. Neither blocks; say what the 48 kHz residue is or that it's out of scope.

Scope

File / group	What it changes	Claimed?	Verdict
Hl2TxDsp.cpp/.h	queue + readiness gate + 1 ms retry timer	yes	in scope
WdspChannel.cpp/.h	outputReady(), same fence as processIq()	yes	in scope
third_party/wdsp/.../iobuffs.c/.h, aether_wdsp.h	new GetChannelOutputReady() export	yes	in scope; new vendored-API surface, documented
iobuffs.c dexchange() reorder	publish-after-copy, applies to every channel, RX included	yes, in the patch doc	in scope but global — see below
AETHERSDR-PATCHES.md	patch 15 entry + numbering note vs #5965	yes	in scope, canon-compliant
tests/hl2_txdsp_capture_burst_test.cpp, tests.cmake	new registered target	yes	in scope

Nothing in the diff is unexplained by #6004. No CHANGELOG.md edit — correct. No settings, no flat keys, no new UI, no preference change. Two things for the maintainer rather than the author:

• The dexchange() reorder changes the vendored DSP for all channels, not just HL2 TX. I convinced myself it's safe (blocking hosts are released by Sem_OutReady, which is signalled after both the copy and the count either way — iobuffs.c:713; for a non-blocking host the credit only becomes visible later, never earlier), but a global change to the shared WDSP core riding a single-backend bug fix is a maintainer call.
• Patch numbering is coordinated with open #5965 in its own commit. Fine, just noting it's a cross-PR dependency on a number.

Sibling call site, checked: Hl2RxDsp::processIqBlock (Hl2RxDsp.cpp:712) has the identical while (… >= block) back-to-back processIq loop against the same non-blocking channel, and its comment even calls Underrun "normal". It is not affected in practice: RX dspBlockSize is 1024 (Hl2RxDsp.h:88) while EP6 deliveries are 126 samples per DDC, so the loop runs at most once per call. Worth knowing that the guard is absent there if RX block sizing ever drops.

Socket tests: none. The new test binds nothing — no QTcpServer/QUdpSocket/bind/listen/connectToHost, no fake peer. It is a socket-free CTest driving real DSP, which is the correct layer per AGENTS.md.

Blockers

1. The stall fallback force-exchanges, which is precisely the corruption this PR exists to prevent — and at the targeted rates it is the normal path, not a rare one. (Hl2TxDsp.cpp:277, Hl2TxDsp.cpp:256, inline)

The gate is bypassed when m_lastExchange.nsecsElapsed() >= exchangeStallNs(), and exchangeStallNs() is one block period — 21.33 ms at 512/24 kHz. But m_lastExchange is restarted on every exchange, so at 24 kHz (42.7 ms deliveries) the gap between the last exchange of one delivery and the first block of the next is ~41 ms, and at 16 kHz ~63 ms. Both exceed 21.33 ms, so the first block of every delivery is exchanged with no readiness check at all — the gate only ever governs the second and later blocks inside a burst.

Usually harmless, because after 41 ms idle the worker has finished. It is not harmless when the worker happens to be behind at that instant — preempted under load, or mid-beginControlOperation() from a setMode/setFilter during the over, where outputReady() returns false by design. Then processIq underruns, and by the PR's own argument (Hl2TxDsp.cpp:270-274, and the patch doc's "every later block boundary is a splice") that one forced underrun ruins the rest of the over. The PR states a fixed time spacing already lost to a loaded worker under ctest -j6; this fallback reintroduces a time-based decision at the one moment the readiness answer is being ignored.

Two things would fix it, and I'd take both:

• Time the wait from when the block became due, not from the last exchange. A block that has waited a whole block period has genuinely been starved; "no exchange happened for a block period" is trivially true whenever the caller is idle.
• On a real stall, drop the block rather than exchange it. Dropping loses 21 ms of audio and keeps the ring in step; exchanging loses the same 21 ms (the output is zeroed) and desyncs the ring permanently. The worker already has input from the previous exchange, so dropping cannot starve it into never producing output. This is strictly better by the PR's own reasoning, and m_txFaultBlocks can still count it.

2. m_lastExchange is never invalidated, so every over opens on the bypass path. (Hl2TxDsp.cpp:216, inline)

resetModulatorState() and buildModulator() clear m_exchangePending and stop the timer but leave m_lastExchange valid and holding a timestamp from the previous over — minutes old. So the first block of every over takes the branch in finding 1 unconditionally. It is probably benign because DiscardTXAChannelData reprimes r2_havesamps (iobuffs.c:509), so outputReady() is true anyway at key-down; but the guard is off at the one moment the channel state has just changed, and that's the wrong place for it to be off. m_lastExchange.invalidate() alongside the two existing clears.

Nits (non-blocking)

• m_exchangePending is unbounded and now silent. (Hl2TxDsp.cpp:245) Before this PR, a caller faster than the channel got counted, logged underruns — the fault counter was the overrun signal. Now the overrun turns into queue depth and transmit latency instead, with modulatorFaultBlocks() at zero. The drain is CPU-bound rather than real-time-bound so a burst does clear, but there is no cap and no warning if it doesn't. A depth watermark with a rate-limited qCWarning would keep the diagnostic the old behaviour gave for free.
• The timer-thread comment states the wrong reason. (Hl2TxDsp.cpp:335-337) A QObject's thread affinity comes from the thread that constructs it, not from its parent — new QTimer(this) from a foreign thread would log "Cannot create children for a parent that is in a different thread" and the timer would never fire. It is correct here only because exchangeDueBlocks() is reachable only from processAudioBlock (queued to m_ioThread, Hl2Backend.cpp:416/5659) and from the timer itself. Worth restating as "only ever called on the I/O thread" so the invariant a future caller must not break is the one written down.
• The new test is wall-clock paced and likely to be flaky in the sanitizer lane. (tests/hl2_txdsp_capture_burst_test.cpp:194) It runs ~6.3 s of real time across three cases, and its own comment concedes the control case fails "if the machine is too loaded to judge the rest" — it fails rather than skips. Under TSan/ASan the WDSP worker and the 1 ms timer both slow down by a large factor while the test's delivery cadence stays pinned to real time; with exchangeStallNs() at 21.33 ms, a slowed worker produces exactly the forced underruns of finding 1 and check(r.faults == 0, …) goes red. It's a registered add_test, so full-suite.yml and sanitizers.yml pick it up. Reasoned from the code, not observed — but it's the kind of failure that gets a target quarantined.
• The patch doc over-claims what the test pins. AETHERSDR-PATCHES.md says hl2_txdsp_capture_burst_test "pins the behaviour". It pins the gate — neuter outputReady() to return true and the test goes red. It does not pin the dexchange() reorder, which is a narrow data race and probably untestable deterministically. Saying so is more useful than implying coverage that isn't there.

What I tried to break

• Startup deadlock. My first suspicion was that outputReady() must be false before any input has been fed — no input, no dexchange(), no r2_havesamps — which would make the gate break on the very first block, arm the timer, and spin forever with zero IQ. It doesn't: create_iobuffs primes r2_havesamps = (DSP_MULT - 1) * r2_size (iobuffs.c:416), so there is exactly one block of credit at channel open and the first exchange proceeds. flush_iobuffs reprimes the same way (iobuffs.c:509), so a discard-and-restart over is also fine. Survived.
• Off-by-one credit. Checked whether the primed credit could permit two back-to-back exchanges: it can only if r2_size > out_size, i.e. dsp_outsize > out_size. For this TX geometry dspSampleRate == outputSampleRate == 48 kHz so dsp_outsize == out_size == 1024 and the credit is exactly one block. Survived — but it is geometry-dependent, not structural.
• Fence and lifetime on the new query. WdspChannel::outputReady() reproduces processIq's m_controlOperation/m_callbacksInFlight sequence verbatim, including the recheck after the increment, so the destructor's drain (WdspChannel.cpp:456) covers it. GetChannelOutputReady takes r2_ControlSection — the same lock fexchange2 takes to read the same counter — so the read is not torn and the CS gives the acquire fence that makes the worker's memcpy visible. Survived.
• The reordered dexchange() against blocking hosts. Traced Sem_OutReady: released at iobuffs.c:713, after both the copy and the count in either ordering, so bfo channels are unaffected and wdsp_channel_test's offline path sees no change. Survived.
• Sibling call site. Hl2RxDsp::processIqBlock loops the same way; cleared on block-size arithmetic (1024-sample block vs 126-sample deliveries), not on assumption.
• Timer lifetime and over boundaries. The timer is parented to this, single-shot, re-armed only while a whole block is pending, stopped by both reset() and buildModulator(), and onExchangeTimer() re-checks permitsDispatch() before emitting — so a lapsed grant drops the tail instead of transmitting it. Principle VI holds on this path. Survived.
• M_PI on MSVC. Flagged it, then cleared it: hl2_txdsp_test.cpp uses M_PI with only <cmath> and builds on check-windows today, because the Qt headers these tests pull in set _USE_MATH_DEFINES. Not a finding.
• CI. All five checks green on e3d9c10 (build, check-windows, check-macos, static checks, sanitizer-configures). Those are compile gates; the per-PR ctest is -R-filtered and does not include the new target, so green says nothing about whether hl2_txdsp_capture_burst_test passes anywhere.

What I could not check: nothing here was run. No build, no test execution, no radio, no macOS QAudioSource. Every finding above is reasoned from the code in /tmp/aetherclaude/pr-6005 and from the vendored WDSP source, and the two claims I most want settled empirically are (a) hl2_txdsp_capture_burst_test under -DENABLE_SANITIZERS, and (b) whether an over with a mid-over setMode/setFilter survives the bypass in finding 1.

Recommendation

Request changes — narrowly, on findings 1 and 2. The diagnosis is excellent and the seam is in the right place: asking the worker instead of guessing at a spacing is the correct call, the WDSP patch is minimal and properly documented, and the underlying trace (advance-without-consume in a two-slot ring) checks out line by line. But the stall fallback's threshold is shorter than the delivery period at exactly the rates this PR targets, which leaves the readiness check switched off for the first block of every delivery, and the action it takes on stall is the one action the PR argues is unrecoverable. Timing the wait per pending block and dropping rather than force-exchanging should be a small change, and it would make the guard hold in the loaded case the PR itself identifies as untested. The nits can ride along or follow.

Thanks for the measurements in #6004 — the per-rate splice table and the "326 of 326 deliveries" figure are what made this reviewable at all.

---

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

[on8st]

It was your third candidate. The first MSVC error in that Build step:

third_party\wdsp\upstream\iobuffs.c(580): error C2375: 'GetChannelOutputReady': redefinition; different linkage

The definition carries PORT (__declspec(dllexport)) and the iobuffs.h declaration did not. MSVC rejects adding dllexport on a redeclaration; clang only warns (-Wdll-attribute-on-redeclaration), which is why macOS and Linux built. Reproduced with clang's MSVC target before the change (warning) and after it (clean). Fixed in e3d9c10 by declaring it the way fexchange2 is declared one line above. All five checks are green on that head.

The other two did not bite: the burst test compiled under MSVC with M_PI and without <cstddef>, so I left it as it is. Your last point stands, though: the Windows lane runs no ctest, so hl2_txdsp_capture_burst_test has still not run on Windows and the 24 kHz fault count there is unmeasured.

ON8ST

[aethersdr-agent]

Antares Detector — candidate vulnerable file(s)

• src/core/backends/hl2/Hl2AdcPairing.h
• src/core/backends/hl2/Hl2Backend.cpp

The Hl2AdcPairing implementation performs ADC slice sampling-rate selection and overload/pairing logic on hardware sample rates (Hz or kHz). It likely maps those values into DSP-usable rates and allocates buffers for processing; without validating that the supplied sampleRate is within an expected range before conversion, it can allocate memory based on untrusted input. The Hl2Backend is implicated because it calls adcPairing to decide slice selection, making this a source of unsafe rate conversion.

_{Localized by Cisco Foundation AI Antares-1B running locally in the AetherClaude sandbox, seeded by the Cartographer security map. Advisory only — please verify before acting.}

---

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

[on8st]

Top-level reply (on the review)

Both blockers were right, and the first one is the bad news: as first posted, this PR force-exchanged in exactly the case it exists for. At 24 and 16 kHz the gap between deliveries (42.7 / 64 ms) is longer than the 21.33 ms deadline, and the deadline ran from the previous exchange, so the first block of every delivery skipped the readiness check. A stall there would have caused the ring desync this PR is meant to fix. Fixed in 423a8ca. Details are in the inline replies.

Two things I cannot close, stated up front:

• The 48 kHz residue in HL2: TX audio spliced when it reaches the modulator in bursts (macOS 24/16 kHz mics, Linux 48 kHz) #6004 is not explained. That table was end to end: BlackHole, AudioEngine, EP2 over loopback to hpsdrsim, captured and demodulated. It shows 6 splices on speech and 5 phase breaks in 5.5 s on a 1 kHz tone at 48 kHz. The 48 kHz control in this test runs the stage alone, and there it is 0. So on this test's evidence the residue does not come from the exchange gate at that grouping. Where it does come from, I have not traced. It is out of scope for this PR, and I am saying so rather than guessing.
• Still not run: the sanitizer lane and Windows ctest. I ran the full suite on macOS only. The change to the test (below) is meant to keep the sanitizer lane from failing on load, but I have not seen it run there.

44.1 kHz is now covered (tests/hl2_txdsp_capture_burst_test.cpp:358, 557 samples per delivery, so roughly every eleventh delivery carries two blocks).

Inline replies

Hl2TxDsp.cpp:278 — Blocker 1

Agreed on both points, and I made both changes (423a8ca):

• The deadline now runs from when a block reached the head of the queue, not from the previous exchange. m_headWait starts when a whole block is at the head (Hl2TxDsp.cpp:320). It is invalidated when that block is exchanged or dropped (:341, :345), and when no whole block is waiting (:384). A block arriving after the caller was idle now waits for outputReady() like any other block.
• On a real stall the block is dropped, not exchanged (Hl2TxDsp.cpp:334). It is counted in modulatorFaultBlocks() and in the new modulatorStallDrops(), and logged through the same rate-limited warning. The next block's wait starts at the drop, so one stall cannot drop a whole backlog. I kept one head-of-queue wait. The reason is the one you gave: "measured from the last exchange" was what made one block period the wrong scale (next thread).

Test: stallIsTimedFromDueAndDrops() (tests/hl2_txdsp_capture_burst_test.cpp:272) makes the worker look stalled through a new seam, setOutputReadyProbeForTest(). The seam can only narrow the channel's own answer, so a test can never exchange into a channel that is not ready. The test checks three things:

• a block that arrives after 40 ms idle is not exchanged while the worker is not ready;
• once the worker is ready, that block is exchanged, not dropped;
• a worker that never answers gets its block dropped once, and nothing is exchanged into it.

Restoring the old gate (deadline from the last exchange, force-exchange) turns this red. Four checks fail: the idle-arrival block is exchanged while the worker is not ready, and the stalled worker's block is force-exchanged instead of being dropped and counted.

Hl2TxDsp.cpp:256 — threshold scale

Agreed. The problem was the reference point, not the length. Measured from when the block became due, one block period means what the comment always claimed: the worker has not turned a block round in a whole block period, and a TXA block normally takes it well under a millisecond. The comment at Hl2TxDsp.cpp:275 now says that.

Hl2TxDsp.cpp:216 — Blocker 2

Agreed, and fixed as you suggested (423a8ca): m_headWait.invalidate() next to the existing clears, in resetModulatorState() (Hl2TxDsp.cpp:219) and in buildModulator() (:104). The lapsed-grant path in onExchangeTimer() (:418) now does the same. With the new deadline, a stale clock would drop the first block of the next over outright rather than bypass the gate, which makes this worse than before, not harmless. So it now has a test of its own: newOverStartsAFreshDeadline() (tests/hl2_txdsp_capture_burst_test.cpp:310). The test unkeys while a block is waiting, keys again more than a block period later with the worker not ready, and checks that the first block is neither exchanged nor dropped until the worker answers. Removing the invalidate from resetModulatorState() turns it red. Three checks fail: the first block of the new over is dropped against the old deadline, is never exchanged, and is counted as a fault.

Hl2TxDsp.cpp:245 — unbounded, silent queue

Agreed on the diagnostic, done (423a8ca, Hl2TxDsp.cpp:257). When more than kPendingWarnBlocks (4 blocks, so more than 85 ms of latency at 24 kHz) are waiting, a qCWarning gives the depth and the latency it adds. It fires once per excursion and re-arms when the queue drains. I did not add a hard cap. With stalls now dropped, a stalled worker drains one block per block period, the same rate the caller adds them, so the queue only grows for a caller that is faster than real time on average. That case is now logged. A cap would drop audio silently in the other direction.

Hl2TxDsp.cpp:337 — timer comment

I have one correction to the review, and I made the change anyway. The old comment did not attribute the timer's affinity to its parent. It said the timer is "created on first use, so it is born on the thread this object lives on", which is the constructing-thread rule. What it left out is the part you named: that is true only because every caller is on the I/O thread. The comment (Hl2TxDsp.cpp:391) now states that as an invariant. exchangeDueBlocks() is only called on the I/O thread, from processAudioBlock() (queued there, Hl2Backend.cpp:5659, after moveToThread at :416) and from onExchangeTimer(). It also says what goes wrong if a new caller breaks that.

tests/hl2_txdsp_capture_burst_test.cpp:194 — sanitizer flake

Agreed, and the exit-77 route is taken (423a8ca). The rate cases now separate two outcomes:

• An underrun always fails. faults == stallDrops (:210). The gate exists so that no exchange underruns, whatever the load.
• A stall drop means the run is inconclusive. A worker held for a block period is load, not the defect, so the envelope, IQ-count and splice checks are skipped and the binary exits 77 (:373). SKIP_RETURN_CODE 77 is set in tests/tests.cmake. The skip is bounded: more than one drop in ten blocks still fails, so a gate that drops everything cannot pass as "load".

The two stall cases do not depend on load: they drive the stall through the seam. Both coverage notes are addressed: 44.1 kHz above, and the patch doc in the next item.

(review body) AETHERSDR-PATCHES.md over-claims

Agreed, corrected in ffdd1e7. The doc now says the test pins the query and the gate. It also says the test does not pin the dexchange() reorder, which closes a cross-thread window that no deterministic test here reaches and rests on the argument in the doc (third_party/wdsp/AETHERSDR-PATCHES.md:791).

73, ON8ST

[on8st]

I wrote earlier that I had not seen the changed test run in the sanitizer lane. It has now been run under the sanitizers, locally, at 5427ee35. Three limits first, because they bound what the result means:

• Leaks were not checked. This was macOS with Apple clang 21, whose ASan refuses to start with detect_leaks=1, so the run used detect_leaks=0. The weekly lane uses detect_leaks=1. A leak in the queue or the timer would not have shown here.
• TSan ran against a stock Qt, not the instrumented one the :tsan image carries. On a stock Qt every cross-thread queued call reports as a race. That affects hl2_tx_gate_test below; it does not affect the two tests that exercise this PR, which produce no report at all.
• It is a subset on one machine, not the weekly lane: six tests, macOS arm64, five repetitions per sanitizer.

Flags, taken from .github/workflows/sanitizers.yml at 25da98de and passed through CFLAGS/CXXFLAGS/LDFLAGS as the workflow does, so WDSP's C sources are instrumented:

lane	build type	compile	runtime
ASan + UBSan	Debug	-fsanitize=address,undefined -fno-sanitize-recover=undefined -fno-omit-frame-pointer	ASAN_OPTIONS=detect_leaks=0:abort_on_error=0:halt_on_error=0:strict_string_checks=1:detect_stack_use_after_return=1:print_summary=1, UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=0:print_summary=1
TSan	RelWithDebInfo	-fsanitize=thread -g3 -fno-omit-frame-pointer -O1	TSAN_OPTIONS=halt_on_error=0:second_deadlock_stack=1:history_size=7:print_summary=1:suppressions=tests/sanitizers/tsan.supp

Configured with -G Ninja -DAETHER_ENABLE_HL2_RECEIVER_CHURN_TEST=ON -DAETHER_ENABLE_HL2_TX_LOOPBACK_TEST=ON, Qt 6.8.3 (this head predates #6055), QT_QPA_PLATFORM=offscreen. Only the six test targets were built. The loopback and churn tests were not built or run.

Results, five runs each:

test	ASan + UBSan	TSan
hl2_txdsp_capture_burst_test	5/5 pass, 0 reports	5/5 pass, 0 reports
hl2_txdsp_test	5/5 pass, 0 reports	5/5 pass, 0 reports
wdsp_channel_reservation_test	5/5 pass, 0 reports	5/5 pass, 0 reports
hl2_tx_level_policy_test	5/5 pass, 0 reports	5/5 pass, 0 reports
wdsp_channel_test	5/5 pass, 0 reports	own checks pass; 3 TSan reports per run, not from this PR (below)
hl2_tx_gate_test	5/5 pass, 0 reports	TSan reports, not from this PR (below)

On the flake the review predicted for hl2_txdsp_capture_burst_test: it did not happen here. The test never took its exit-77 route. In all ten sanitized runs every rate case printed faults 0 (stall drops 0) ... splices 0 (40 of 40 case lines), at about 10 s per run under ASan and 12 s under TSan against the worker. That is one 12-core machine with up to six tests running at once; it does not show the lane's runner behaves the same.

The TSan reports, and why they are not this PR's:

1. wdsp_channel_test: data race TXA.c:822 (and :823, :824) in TXASetupBPFilters, against xbandpass bandpass.c:321 on the WDSP worker, reached through WdspChannel::setFilter (WdspChannel.cpp:713). Neither TXA.c nor that line is in this diff. It reproduces at 25da98de with the same three SUMMARY lines, and it is the report the weekly lane already tracks in [sanitizer] TSan weekly run failure (fp 4fd7a70228fc) #5831 (and repeats in [sanitizer] TSan weekly run failure (fp 596465812892) #5959).
2. hl2_tx_gate_test: 58 to 68 reports per run, 10 distinct signatures. In every one, one side is a functor being run or destroyed by QObject::event on the I/O thread and the other is the same functor being built in QMetaObject::invokeMethod on the caller (Hl2Backend::applyKeying, Hl2Backend.cpp:5000; the test's own packet() helper, hl2_tx_gate_test.cpp:86). That is the stock-Qt class the workflow file describes. All 10 signatures reproduce at 25da98de; none is in a file this PR touches. The weekly lane's failing list at 33c0032 ([sanitizer] TSan weekly run failure (fp 596465812892) #5959) does not include this test.

One extra check, because tests/sanitizers/tsan.supp suppresses fexchange2 and upslew2, and patch 15 edits iobuffs.c right beside them (GetChannelOutputReady, and dexchange publishing r2_havesamps after the copy): I ran the two tests that drive patch 15 under TSan once more with no suppression file. hl2_txdsp_capture_burst_test three runs, hl2_txdsp_test one run: 0 reports, all pass. So the suppressions hid nothing in those two tests.

Positive control for the ASan + UBSan lane: a small program with a signed overflow and a heap use-after-free, built and run with the same flags and options, reports both.

Still not run: the weekly lane itself (Linux, instrumented Qt, leak detection on, whole suite), and Windows ctest.

73, ON8ST

[ten9876]

Approving at 0fee91cd. That is on8st's fix, plus my 79f016e5, plus two GitHub update-branch merges of main (#6007, #6021). Neither merge overlaps the files this PR touches.

Fixed in this pass (79f016e5)

1. The stall cases could fail under load. The automated review pass found that both seam-driven cases held a fake stall for about 3 ms of wall clock against the 21.3 ms drop deadline, and failed outright if the process was descheduled past it. They now time the hold from the delivery. A hold that outlives the deadline marks the case inconclusive (exit 77, as the rate cases already do), and a drop inside the deadline still fails. A forced 25 ms hold gives rc=77 with no FAIL lines.
2. Hl2TxDsp.h was stale. The processAudioBlock() comment said a caller faster than real time "gets Underrun". With the gate it grows a warned queue, and the comment now says so.
3. Patch 15's doc was missing two things. AETHERSDR-PATCHES.md now states what the dexchange() reorder does to RX and gives its upstream status. On RX, the count becomes visible one memcpy later. Priming, ring indices and Sem_OutReady are untouched, so no channel gains latency. An exchange that lands inside that window underruns, where upstream's order handed back a torn block. Upstream status: TAPR 2.10 still counts before it copies, and there is no query. The doc also records a spin-host measurement: torn blocks in 3 of 15 runs with upstream's order, and 0 of 20 with the reorder.
4. Comments now follow AGENTS.md § Comments. The test header, the iobuffs.c patch comments and the review-history references are cut down.
5. PR body. I removed a stray SHA line, described the stall path as it is now (drop, not exchange), and listed 44.1 kHz.

Verified (Linux, local)

• Mutations. Each of these turned hl2_txdsp_capture_burst_test red:

  • gate disabled: 14 FAILs, 82 splices at 24 kHz;
  • patch 15 reverted (query returns 1, reorder undone): 9 FAILs;
  • query alone returns 1: 9 FAILs;
  • stall drop replaced by exchange: 3 FAILs;
  • resetModulatorState() invalidate removed: 3 FAILs.

  Reverting only the reorder stays green in this test, as the patch doc states. It is supported by the spin-host measurement instead.

• Plain runs. The burst test passed 5/5, and 5/5 again under 16 CPU hogs, with every rate case at faults 0 (stall drops 0) ... splices 0.

• ASan+UBSan, leaks on, C instrumented. The burst test passed 5/5 with zero ASan and zero UBSan errors. All 12 wdsp_*, hl2_rxdsp* and hl2_txdsp* tests pass. LSan reports only create_calcc (calcc.c:1079, the PureSignal semaphores never closed). That is upstream code, and the unchanged hl2_txdsp_test and wdsp_channel_test leak from the same frame, so it is not this PR's.

• Full ctest. I ran 546 tests on the merged head, with socket-owning tests excluded. All pass except connection_panel_size_test, a known local failure (#5811).

• Static gates. check_engine_boundary, gen_touchpoint_manifest --check, check_capability_records and check_command_plane give output identical to the merge base.

Not verified: Windows ctest, the weekly TSan lane, and a live HL2. No transmitter was keyed.