Repository navigation
Make pcmdump's settle and capture adjustable, so SETTLE_MS can be measured; versionCode 14 - #4
Merged
Merged
Conversation
…sionCode 13 SETTLE_MS is the pause the calibrator takes after writing a latency, before it trusts the audio it records. It was never measured. Answering that costs a rig session at ~7 minutes per calibration, per candidate value. dumpCapturePcm already does the essential part - it commands a known offset (SWEEP_PROBE_MS), settles on its own hardcoded 7 s, and dumps the ref+mic PCM - so exposing that settle turns each data point into a ~40 s dump analysed offline. Nine dumps took seven minutes where nine calibrations would have taken an hour, and the commanded offset is ground truth: recover it and the settle was long enough. Debug-gated like the rest of the dbg hooks, and the default is the production value, so nothing changes unless --ei settle is passed. Kept rather than reverted because the question it exists to answer is still open: full-capture lag recovery turned out to be insensitive to the settle (0 ms recovers the commanded offset as well as 7000 ms), and the split-half gate that could discriminate is noise-dominated on this rig even at 75 %. Re-running at better SNR needs this hook.
--ei capture <ms> alongside the existing --ei settle. Debug-gated, default unchanged. The hypothesis was that the production 12 s capture hides a too-short settle by averaging: the audio in flight when a latency is written is ~1.15 s, only ~10 % of the window, so shrinking the window to 2 s should make the contamination dominate and move the peak. Rig-tested at 2 s, alternating settle 7000/0/7000/0 so drift could not pose as an effect. It made no difference - all four recovered the commanded 380 ms offset within ~4 ms, and the absolute drift was -20.5 to -0.1 ms with no grouping by settle. The hypothesis was wrong, and the reason is worth recording: the probe separates one client RELATIVE to the other, both arrivals land in the same capture against the same reference, so audio still in flight delays both together and cancels in the spacing. That quantity is insensitive to the settle by construction, not by averaging, and no capture length changes it. Kept because the knob is what established that, and because the level path - which is NOT differential, and which SETTLE_MS also precedes - still needs testing.
guerman5
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SETTLE_MSis the pause the calibrator takes after writing a latency, before it trusts the audio it records. It runs 4-8 times per calibration — 28-56 s of every run — and was never measured. Answering that costs a rig session at ~7 minutes per candidate value.dumpCapturePcmalready does the essential part: it commands a known offset (SWEEP_PROBE_MS = 380), settles on its own hardcoded 7 s, and dumps the ref+mic PCM. This exposes two knobs on that debug path:--ei settle <ms>— the post-probe settle, turning each data point into a ~40 s dump analysed offline. Nine dumps took seven minutes where nine calibrations would have taken an hour, and the commanded offset is ground truth.--ei capture <ms>— the recording length, added to test whether the 12 s window was hiding the effect.Both are debug-gated like the other
dbghooks, and both default to the production values, so nothing behaves differently unless the extras are passed.SETTLE_MSitself is unchanged, and nothing here argues for reducing it.What the experiment found
Full record in
FINDINGS-settle-ms-cost-2026-08-25.md(untracked docs dir).A settle of 0 recovers the commanded 380 ms offset as well as 7000 does — at 12 s (8 dumps, ~4 ms, PHAT and Wiener agreeing) and again at 2 s (4 dumps, alternated 7000/0/7000/0 so drift could not pose as an effect).
The first reading of that was "the 12 s capture averages the contamination away, so shorten it". That was wrong, and the 2 s run is what proved it. The real reason is structural: the probe separates one client relative to the other, both arrivals land in the same capture against the same reference, so audio still in flight delays both together and cancels in the spacing. Absolute drift across the 2 s dumps was -20.5 to -0.1 ms with no grouping by settle. No capture length changes a quantity that is insensitive by construction.
Why keep the knobs
They are what established the above, and the question is not closed. The level path is not differential — a level read during the drain sees the old gain, with no second arrival to cancel against — and
SETTLE_MSalso precedes the balance's level reads. That is the one place a short settle could still plausibly hurt, it is untested, and--ei settlealready supports the experiment: hold the geometry fixed, change a client's volume, vary the settle before a level read.