Field notes · 13 Aug 2026

1,234 taps later: why Android drums early

We put a browser rhythm game in front of LinkedIn, logged every tap on the server, and found a platform-shaped hole in our timing model. Here's the data, the diagnosis, and the fix that shipped today.

OneDrum is a certified-timing engine: it certifies synchronicity — did you answer a shared beat in time — server-side, against the clip's own timeline, and hands the result to anyone as a signed number. Viking Row is the first experience built on the engine: a call-and-response drum chant where the drum calls on beats one and two and you answer on three. Every answer lands in a database with its timing delta, because the spec made us a promise we intended to keep: start the acceptance window at ±90ms, then tune it from logged deltas, not vibes.

After we shared Viking Row on LinkedIn, real players gave us the dataset: 84 sessions and 146 runs across desktop, iPhone and Android — 1,234 genuine scoring attempts after we excluded warm-up bars, wrong-beat taps and our own test harness.

What the deltas said

Each player self-calibrates in the first bar — their opening answer measures their device's audio-plus-touch latency, and every later tap is corrected by it. If that works, post-calibration deltas should centre on zero. On two platforms, they do. On one, they don't:

Desktop and iPhone are centred — calibration is doing its job. Android is another story: it missed nearly twice as often, and its misses are not noise. 119 early against 6 late is a signature, not a scatter.

The diagnosis

Our clock is the audible one: we derive clip time from the audio system's own report of what's currently leaving the speaker, so a player who taps with what they hear scores a delta near zero regardless of their hardware's latency. That report is the weak link. On Android Chrome, the reported output latency drifts after the first bar — the calibration offset, correct when it was measured, is stale five bars later. The derived clock falls behind the real sound, and every honest tap gets stamped a few dozen milliseconds early.

Our adaptive-calibration safety net couldn't catch it, for a reason that's obvious in hindsight: it only arms before a player is calibrated. These players calibrated perfectly. Then their device quietly moved the goalposts.

The fix that shipped

The durable fix is continuous drift re-centring in the scoring kernel, and it's on the roadmap. But the data also showed the window itself was tighter than it needed to be: widening ±90ms to ±120ms — exactly a sixteenth note at 120 BPM, a cleaner musical definition of "in sync" — lifts acceptance of genuine attempts from 76.5% to 84.1% overall, and Android from 60% to 71%, while staying tiny against the two seconds between scored answers. A random tap still fails ~88% of the time, and our variance-based bot detection doesn't care about window width at all.

That change is live now. Same game, same certification, fairer to a third of the planet's phones.

Why we're telling you this

Because the engine is the product. Anyone can render a beat in a browser; the hard part is certifying synchronicity across devices whose clocks lie in device-specific ways — and the only way to get that right is to instrument everything and let production data overrule your assumptions. Viking Row is the first experience on the engine, and its players are also its field study: one LinkedIn post bought us 1,234 attempts, and every certified score it issues is a number an operator can verify against the OneDrum API without trusting the device that produced it.

Try Viking Row — the drum calls, you answer: onedrum.io

Method notes: deltas are post-calibration, from the server-side taps log. "Genuine attempts" excludes warm-up-bar answers, taps more than 250ms from any cue (a wrong beat, not a timing miss), and scripted/QA traffic identified by device class. Acceptance percentages are of genuine attempts. · More field notes