Fix SRS transmissions being split into fragments

[dharmab]

Context

The SRS protocol has no end-of-transmission marker, so pkg/simpleradio/receive.go infers transmission boundaries from a silence gap. Three bugs in that logic split a single utterance into fragments, which reach whisper as garbled or duplicated requests, or fall under minRxDuration (1s) and get discarded with no log line explaining why.

Design

The channel owns the transmission window, not the caller. A window opens when a packet arrives on an idle channel and closes when no packet has arrived for the grace period. Each receiver's window is evaluated independently, the way a GCI monitoring several frequencies hears each one separately. Within a window the first transmitter wins and anyone stepping on them is dropped.

The three splitting bugs

	Was	Now
Queue coupling	Publishing was gated on len(in) == 0, so traffic on any frequency — including ones no radio is tuned to — could hold another channel's transmission indefinitely	The tick drains the queue, then evaluates each deadline independently
Stale-buffer lockout	"In progress" meant state has not been reset, not the deadline has not passed, so a finished-but-unpublished transmission locked out the next caller	Completed transmissions are published before each packet is buffered
Phantom windows	Packet numbers reset to zero on publish, so a delayed packet was mistaken for a new transmission — buffering a stale frame, arming a fresh deadline, blocking the next real caller	High-water mark kept per transmitter across transmissions

Verified against a live server

Captured 1180 packets from eu.limakilo.net (receive only, never transmitted):

• Two transmissions 400.9s apart carried consecutive packet numbers (delta = 1, IDs 3626329→3627508, zero loss). This is the direct confirmation that the reset-to-zero was wrong.
• Inter-packet gaps: p50 40.0ms, p95 42.2ms, max 52.0ms — the 300ms default has ~6× headroom, so I kept it rather than raising it.
• Framing 6+31+40+58 = 135 = datagram size, confirming voice.Decode's framing validation (shipped separately in Validate SRS voice packet framing in decoder #721) doesn't reject real traffic.

⚠️ Confirming that assumption also showed relying on it was dangerous. A client that restarted its numbering would fail PacketID <= highWaterMark forever and be silenced permanently — strictly worse than the stale packet the check exists to reject, and something the old code tolerated by accident. A backwards packet number now only counts as stale within 2× the grace period of that transmitter's last packet. Test: TestReceiverAcceptsRenumberedTransmitter.

Also in here

• --srs-split-transmission-grace-period, default unchanged at 300ms
• Wall-clock span logged next to audio duration, so "short transmission" and "lossy transmission" are distinguishable
• Receiver lock taken for every access (waitForClearChannel read a deadline unlocked, publish read the buffer unlocked, coalition filter read clients without clientsLock)

Testing

Regression suite for the receiver: window opening/closing, grace-period boundaries, duplicate/out-of-order/renumbered packets, capture effect, truncation at MaxTransmissionDuration, the queue-coupling fix, and the waitForClearChannel lock fix. Time-dependent tests use testing/synctest, matching pkg/controller.

make test && make lint vet fix format && go mod tidy   # all pass, no further changes
1250 tests, race detector clean

Mutation-checked the regression tests by reverting each fix. One caveat: the break after the first frequency match is now dead defense — the per-transmitter dedup already rejects the repeat, so removing it fails nothing. Kept it to avoid a redundant locked call, but it isn't load-bearing.

Not verified: whether the SRS server filters voice packets by frequency server-side, which is what sets bug 1's real-world severity. The controlled capture on a bogus frequency didn't happen, and the observed packets listed four frequencies I was partly tuned to, so they prove nothing either way. The fix is structural — publication no longer consults queue depth at all — so severity doesn't change the code.

🤖 Generated with Claude Code