A stored τ can be 16 samples wrong the next session with every TauConditions field matching

[mkovero]

observation

Same rig (pupu, FF400), same electrical loopback (system:playback_2 → system:capture_2), same JACK settings (96000 Hz, period 256, -S), measured by ac calibrate on two days:

session	build	τ	samples @ 96 kHz	record
2026-09-14	cb95c5aa	17.989583 ms	1727	PR #384 comment "rig-2026-09-14-pr384-tau-snr"
2026-09-15	298f77dc	17.822917 ms	1711	#347 comment (this session)

16 samples apart — 0.167 ms — and not a multiple of the 256-sample period.

what it is not (measured 2026-09-15)

• Not the build. The 2026-09-14 build cb95c5aa, still staged on the rig and sha256-verified, read 17.8229 ms ×3 on 2026-09-15.
• Not a JACK restart. jack-ac.service was stopped, jackd run by hand at 48 kHz, the service restarted at 96 kHz and the FF400 baseline toggle-restored; τ then read 17.8229 ms ×5, identical to before the restart.
• Not within-session instability. 44 calibrate runs across both rates, within one daemon and across 10 daemon restarts each, agreed to the sample (τ must be measured more than once: a single reading can be one period wrong with nothing to detect it #347 record).

Cause is not identified. What changed between the sessions and is not in the table above includes at least: whatever state the FF400 / firewire stream came up in after the 2026-09-14 session ended, and the cabling work done on 2026-09-14 (outputs re-probed and recabled that day). No mechanism is claimed here.

why it matters

TauConditions keys on device, backend, sample rate, period size, output port and input port. Every one of those matched across the two sessions, so a τ stored on 2026-09-14 is resolved on 2026-09-15 as a valid match and applied 16 samples wrong, with nothing refused and nothing printed. #347's two-readings-agree rule cannot see it either: both readings in a run share the session's offset.

Epic #276's definition of done says τ "refuses rather than degrades" on mismatch. This is a degrade with no mismatch to refuse on. At 96 kHz, 16 samples is 5.7 cm of acoustic path — above the rig's 5 cm "good enough" bar.

acceptance criteria

• Determine whether the shift is reproducible across a power cycle or cable re-seat of the same loopback, with same-build τ measured before and after — provenance: measured. Until that exists, any fix is guessing at the mechanism.
• Whatever is stored says when (session, and ideally interface power/stream epoch) τ was measured, and an operator-facing read-out distinguishes "measured this session" from "resolved from a stored entry" — so a reader can tell which one they are trusting.
• If the shift reproduces: stored τ is either refused across that boundary or flagged as unverified for the current session, with the boundary named. A silent match is not acceptable.

related

#347 (τ agreement within a run), #281 (τ as a scoped calibration layer), #359 / #363 (period-sized jumps), #276 (epic definition of done), #351.

[mkovero]

reproduced — a reboot moves τ, in whole multiples of 16 samples

pupu, 2026-09-15, same staged build 298f77dc (sha256-verified), same AN2 → IN2 loopback, −40 dBFS, operator-approved test A. Each row is 5 calibrate runs: 3 on one daemon, 2 after daemon restarts.

state	τ	samples @ 96 kHz	Δ vs today's baseline
2026-09-15 before reboot (plus 22 runs earlier incl. a JACK restart)	17.8229 ms	1711	0
2026-09-14 (PR #384 record)	17.9896 ms	1727	+16
2026-09-15 after systemctl reboot (JACK restarted, FF400 baseline toggle-restored, −60 dBFS probe IN2 −57.5)	18.1562 ms	1743	+32

Stable within one boot (5/5 identical), captured level −40.6 dBFS unchanged. Every value so far is 1711 + 16k.

What moves it and what does not, measured: not the build (#461 body), not a JACK restart (earlier today, τ unchanged). A reboot does. The step therefore happens below JACK: the FireWire driver or isochronous stream start-up, or the interface's response to a bus re-initialisation.

Why 16. Linux sound/firewire/amdtp-stream.c, amdtp_syt_intervals[]: CIP_SFC_48000 = 8, CIP_SFC_96000 = 16, CIP_SFC_192000 = 32. Looked up in current kernel source, not recalled. Every step here is a whole multiple of the 96 kHz SYT interval. This is a strong fit, not an established mechanism. It predicts steps of 8 samples at 48 kHz, which is the test that would separate it from a coincidence.

ALSA status at each state (instantaneous, pointer-position dependent, so indicative only): before the reboot, playback delay 1056 and capture 480; after it, 1408 and 144.

Not yet run: test B, an FF400 power cycle with the host up. Pending the operator.

Bearing on the fix. A stored τ is not a property of TauConditions; it is a property of the stream epoch. Across epochs it moves in SYT-interval steps that no field in the conditions tuple records. See #460 for what this does to the causal bound's error budget.

[mkovero]

test B — an interface power cycle re-picks τ too

Same build 298f77dc, same AN2 → IN2 loopback, −40 dBFS, 5 calibrate runs per state. FF400 power-cycled by the operator with the host up. The device re-enumerated on the FireWire bus under a new node; JACK was restarted and the interface baseline restored and verified by −60 dBFS probe (IN2 −57.5 dBFS) before measuring.

event	τ	samples @ 96 kHz
2026-09-14 session	17.9896 ms	1727 = 1711 + 16
2026-09-15, before reboot	17.8229 ms	1711
after host reboot (test A)	18.1562 ms	1743 = 1711 + 32
after FF400 power cycle (test B)	17.8229 ms	1711

Each row: 5/5 identical, both readings agreeing, captured −40.6 dBFS.

What the four epochs show:

• τ takes a value from 1711 + 16k each time the interface is enumerated: host boot, or device power-on (a bus reset either way). Between enumerations it held on every run.
• A stream restart alone does not re-pick it. Earlier on 2026-09-15 jack-ac was stopped, jackd run at 48 kHz and restarted at 96 kHz twice (τ must be measured more than once: a single reading can be one period wrong with nothing to detect it #347 record). τ was unchanged at 1711 throughout.
• k has taken 0, 1 and 2. Whether it is bounded is unmeasured.
• 16 samples is amdtp_syt_intervals[CIP_SFC_96000] (Linux sound/firewire/amdtp-stream.c). This is the fitting candidate mechanism; the untested prediction is 8-sample steps at 48 kHz.

Consequence for any stored τ: it is valid only within the device-enumeration epoch it was measured in. Nothing in TauConditions records that epoch. On this interface the error across epochs is a whole number of 16-sample steps, in either direction.

Side finding, rig infrastructure only: the reboot moved the interface's ALSA card number, and the rig's interface-control service was pinned to the old number. After the power cycle the interface therefore came up with no stream routing (silent). That is fixed on the host, and details are in the private host notes. It did not affect any τ value above: every row was measured with routing verified by probe first.

[mkovero]

a power cycle that did not move τ (pupu, 2026-09-16)

During #460's AC5 run the FF400 was power-cycled once, mid-protocol. It genuinely re-enumerated — same GUID 000a3501f47a94b9, node moved fw2.0 → fw1.0, jackd restarted (pid 1759 → 7619), and the device lost and regained its mixer routing in between.

τ on the AN2→IN2 loopback read 1711 samples before and 1711 after, in five captures either side.

That adds a data point to this issue's series (1711 on 2026-09-15, 1727 on 2026-09-14, 1743 after a reboot): not every enumeration moves it. So the shift is not a deterministic consequence of re-enumerating — this cycle happened to land on the same SYT phase — which matters for how anyone bounds "how many steps are reachable". A per-session check for stored τ (#466) cannot assume a cycle will reveal itself.

One more observation from the same boundary, in case it is relevant to the mechanism: levels did not survive the cycle while timing did. The −60 dBFS wiring probe read IN2 at −54.5 dBFS where the record says −57.5 (+3.0 dB), and an IR peak measured either side moved −13.4 dB — with τ and the measured arrival unchanged to the sample.

[mkovero]

tracked under EPIC #475 — τ trust

Role here: the measured staleness. τ re-picks by a multiple of 16 samples on every device enumeration with every TauConditions field matching — 1711 → 1743 → 1711 on pupu. #460 removed this from the causal bound's path by reading τ from a same-capture reference; this issue covers stored τ everywhere else. Sequenced before #466.

The epic groups this with #346, #347, #350, #351, #359, #363, #461, #466 and #467 because they share one mechanism — latency moves in discrete quanta (one JACK period per client start; 16 samples per FireWire enumeration) that TauConditions cannot see — and one signature: a number that is stable, repeatable, physically plausible and wrong.

Backlink only. No routing, scope or priority change to this issue.