aqua-feel sync: off-grid hits, a ramp detector, the Playground

2026-11-11. Follow-up to the Perlines v2 page. Same recorder (rec.cjs), headless Chromium with software GL, 640x360, ten hits per 12 s clip; the Playground recorder is pg-rec.cjs. Default profile (audio may lead 25 ms, lag 100 ms). Code: GameCult/AquaSynth tools/aqua-feel, SYNC.md.

1. Hit times off the 60 Hz frame grid

New WAV clicks-offgrid.wav (hits at 1.013, 2.241, 3.127, 4.389, 5.306, 6.652, 7.519, 8.834, 9.707, 10.943 s; list). The first page's identical -15.9 ms on every hit was the grid, as suspected. Two takes per scene, step detector and ramp detector (section 2) on each:

The real spread of the step detector on a software-rendered capture is 25 to 64 ms within one take (per-hit lag, min to max), and the median moves by up to 34 ms between two takes of the same scene (Burning water: -0.1 and +33.6 ms). So these clips cannot support a latency claim tighter than about +/-40 ms for the app, and cannot say which take is typical. Where the spread is small (24 to 29 ms) it is still the capture: frames arrive 17 to 50 ms apart. A real GPU is the missing control. Clips: Aurora take a, Burning water take a, Vector trails take a (other takes' reports are listed; their video is not kept).

2. Ramp detector (--shape ramp, PR #34, open: a third Soul pass has not reported, not merged)

On Vector trails the step detector pairs 0 of 10 hits in both takes; the ramp detector pairs 10 and 9 (see table). That is a recovered detection, not a recovered measurement:

• It can claim: the picture had started to change by a given frame (the first raw frame 20% of the rise above the quiet level, at least 4 noise sigmas). If the sound still came later than 100 ms after that frame, the verdict is audio-late-detectable, whatever the swell's shape.
• It cannot claim: that a swell is in sync. A ramp is never reported inside-window or audio-early-detectable, because a swell's start cannot be bounded from below by looking at it. Every ramp row above is therefore borderline (or ambiguous), which says "not shown late", not "fine". It also cannot say when anyone sees the swell begin or that this sound caused it; a bed that swells on its own makes false pairs.
• How it got here. The first version printed tighter intervals and verdicts of all kinds. A separate-context Soul pass found it wrong in both directions (a smoothing window crossed before the picture, so fast rises were called late inside the window; slow-start shapes were called early or inside while in sync). Those verdicts were removed rather than patched, and the failing cases plus a 120-case sweep are tests.
• The point lags in the table (the foot of a line through the 20% and 80% crossings) differ from the step detector's by 20 to 80 ms on the same clip because they define "start" differently; neither is when a viewer sees it.
• Constants were set on Vector trails and synthetic ramps only.

3. AquaSynth Playground UI

The Playground (static page, 808-kick, published build 6080f9b, served locally) answers a sound with one thing that moves: the <meter id="level"> output-peak bar, written by the page's own animation loop from an analyser. It has no video to screen-record in a headless browser, so this is not a picture-and-sound clip. Instead pg-rec.cjs records (a) every write the app makes to the meter value with its timestamp, (b) the app's audio output sample-accurately through an AudioWorklet tap placed at the destination, and (c) the Play-click times; the audio clock and the page clock are bridged with getOutputTimestamp(). Six Play presses 1.5 s apart, four takes. Files: wav, meter track, presses (first take as pg-kick.* and pgk-0), screenshot.

Lag = audio onset minus meter onset; positive means the audio comes after the meter moves. In every take the meter moves 3 to 33 ms after the click and the sound lands 25 to 68 ms after the click, so the meter leads the sound by 4 to 56 ms (median across takes 23 to 39 ms) and all 24 pairs are inside-window by the default profile. That is a statement about the app's own meter and its audio graph, not about anything on screen. Whether a person perceives a meter 25 ms ahead of the sound as in sync is exactly the check that is still owed.

Where the limits show.

• Bridge noise. getOutputTimestamp() jitters: the clock offset's spread over a take was -0.1..+33 ms, -10..+8, -30..+10 and -20..+20 ms (takes 1 to 4). Per-hit lag spread (14 to 47 ms) follows it. Take 3 and 4 spreads (41, 47 ms) are mostly this. The audio tap also reported 0 to 2 dropped 128-sample blocks per take.
• The kick is not one onset. With default settings the tool finds about five audio onsets per kick (a pitch sweep re-triggers the spectral flux) and marks every press ambiguous-pairing. These results use --min-gap-ms 600 --pair-window-ms 120 (hits are 1.5 s apart). Without that the tool would have said it could not judge.
• No real output chain. A headless browser with no audio device. Speaker, display or Bluetooth latency is not in any number. The meter is a bar drawn from a 1024-sample analyser window (23 ms), so it is a coarse visual by construction.
• One patch (808-kick), one browser, one machine. The Playground's other patches and its sliders were not exercised.

Still owed

A person watches and listens to a clip the tool calls inside-window and one it calls late and says whether the verdict matches; the 25/100 ms windows are checked against the standards texts; a capture on a real GPU and display.