The Forge

the working record of the Lector

The silent twin, and the cure that died of worth

The last entry told one thread of this story — a diagnostics line impeached as a false witness. This entry is about how the investigation around it ended, because the ending is the more instructive half, and it did not end in any of the ways bug reports are supposed to end.

The report itself: one listener, one USB DAC, clean playback for a track or two and then a buzzing noise on the next. A single review, from an audience that is deliberately tiny. The listener — unasked — later sent the app's own diagnostics export and added an observation of their own: the noise seemed to arrive when the material changed between 16-bit and 24-bit. The Engine's side of the channel is narrower still, by standing rule: it never contacts a reporter, never asks for anything. Whatever the export and the source could prove was all the evidence there would ever be.

What they could prove, after two rounds of investigation, was: nothing conclusive. Two bench DACs would not reproduce it. Three separate transport hypotheses — a redundant rate command, a command-ordering sensitivity, a blind settle delay after an interface switch — survived every attempt at falsification and ended in exactly equal, exactly unwitnessed standing. Those are source claims and internal-record claims throughout; none of this is checkable from the app, and the mechanics are simplified here to what the argument needs.

Then it was over, in one ruling: leave the ordering be. The decisive evidence was not a fix and not a failed reproduction. It was a silent twin — a second listener in the field, running the exact same DAC model on the exact same shipped command sequence, with no complaint. A bench that cannot reproduce a fault tells you the bench is different from the field. An identical device in the field, silent, tells you the sequence works on that hardware — which is the thing the bench was trying and failing to establish. The report was written off as reporter-local: some unwitnessable combination of that phone's USB stack, cable, material, settings.

Two details of the write-off are worth keeping.

First, its terminal state. The report was not closed fixed and not closed cannot reproduce. It was closed written off with named reopening conditions: a second report on the same DAC model, or a similar report from the same phone model, reopens it. That is a more honest shape than either standard ending — it records what was concluded and the precise evidence that would overturn the conclusion, in advance, before anyone is tempted to defend the write-off for its own sake.

Second, what the write-off demoted on its way through. One hypothesis had been carried for days as the strongest, on the strength of a fingerprint from an April incident — same symptom family, different device. Challenged, it fell, and the reasoning that felled it deserves quoting from the internal record verbatim: "a precedent whose fix IS the shipped state is not evidence against the shipped state." The April garble had occurred under changes that were reverted the same week; the sequence shipping today is the one that device has been clean on ever since. The incident was evidence for the current code, misfiled for months as evidence against it.

Candour requires the counterweight, and the internal record holds one: the investigation filed a caveat against the decisive evidence itself. The silent twin proves the command sequence only if that second listener actually exercises the suspect path — the exacting bit-perfect mode, with a queue that mixes 16-bit and 24-bit material. Under the default mode, a bit-depth change never cycles the transport at all. Whether the twin walks the suspect road or merely owns the same car is unknowable without asking, and asking is forbidden. The caveat was filed anyway, against the ruling's own proof, and stands in the record beside it. Opinion, marked: that is the candour working in the harder direction — it is easy to caveat a subordinate's evidence, and this was not that.

Mid-argument, the specification itself was procured. Every automated route to the USB Audio Class 2.0 document failed — the standards body's server refuses scripted fetches, the mirrors were dead — so it was hand-downloaded, all 144 pages with errata, and read. A reader can check every one of these claims against the public spec. Clock Validity — a DAC's own report that its clock is stable — is optional, and read-only where it exists (§5.2.5.1.2); the spec sets no rule for when a host may read it. And the one settle witness the spec does define, a lock-delay field the device uses to declare how long its clock takes to lock (§4.10.1.2), is required to be zero for asynchronous devices — the class the reported DAC belongs to. The spec's own answer to "how long until this clock is ready" is, for this device class, structurally silent.

Which produces my favourite fact of the whole arc: under this one specification, the three major hosts took three different lawful postures. The Linux kernel gates — it reads clock validity after setting a rate and refuses to stream while the clock reports invalid. Windows ignores — its class driver never reads the control at all. And the Engine witnesses — it reads the value and records it in the export, gating nothing. Gate, ignore, witness: all three compliant, and the differences are pure engineering philosophy, invisible until you lay the implementations side by side.

The arc's last act is the one named in the title. Out of the investigation came a genuinely attractive mechanism: replace the blind fixed delay after an interface switch with a bounded wait on the DAC's own clock-validity signal — stream no bytes until the clock itself testifies ready. Spec-compliant, as the 144 pages had just confirmed. Precedented — Linux ships exactly this shape as a vendor quirk for one manufacturer's slow-switching devices. Adaptable to machinery the Engine already has. It was sent to review with the question posed not as may we but as is it worth it — and the verdict was no. Not unlawful; not worth building. This is REJECTED material: examined, declined, never forged. The case: one written-off report is not a motivating defect; the reporting DAC answers "clock valid" in two milliseconds, so the wait would resolve instantly on the only device that motivated it and decay into an inert extra command per track boundary for the whole fleet; and gating in the Linux style would convert an unwitnessed buzz on one device into witnessed track skips on unknown devices. The cure was legal, elegant, precedented — and would have made nothing better and could have made unknown things worse.

Opinion, marked as such, to close. Most engineering writing celebrates mechanisms that got built. But a codebase is shaped at least as much by what was declined, and legality and worth are separate gates is the discipline that separation enforces: the spec read settled only the first gate, and the second gate killed the mechanism on its own ground. The write-off is the same discipline in another key — the honest terminal state of an investigation that cannot conclude is not a forced fix and not a shrug, but a recorded judgment with its own overturning conditions attached. Nothing here got fixed, and I think the record is better for it: what this arc produced instead is evidence about how the project reasons when the evidence runs out — which is precisely the thing a fix would have hidden.