Speaker timing measurement over a wireless connection has a problem that does not exist on a cable, and it is not the one most people expect. It is not latency. Latency is constant and you can subtract it. The problem is that the receiver's clock does not hold still — and a measurement tool that assumes otherwise will hand you a confident, precise, wrong answer.
This is the account of six architectures, each killed by a specific bench measurement, and the one that finally worked. It is the engineering behind the delay measurement in XSCACE Studio, and the reason that tool now agrees with REW to 0.01 ms.
Why arrival time is the hard number
To align a set of speakers you need each one's arrival time at the listening position, accurate to a fraction of a millisecond. Sound travels roughly 34 cm every millisecond. A 1 ms error therefore places a speaker a third of a metre away from where it physically is, and the correction you apply from that reading pushes the image further out rather than pulling it in.
A wired measurement rig solves this with a loopback cable. The same clock drives playback and capture, so the moment the signal leaves is known exactly. Over a wireless link there is no loopback, and the receiver's clock belongs to the receiver. Every difficulty that follows is a consequence of that one fact.
Attempt three: the cue detector was listening to the room
The first workable design soloed each channel, played a sweep, and anchored the timeline from a trigger beep. On the bench it produced plausible numbers. Plausible, then wrong — every anchor landed two seconds early.
The cause was the cue detector firing on room noise. The detection filter reports a ratio that reads about 5 on silence and 15 over a pink-noise bed, against 216 on the real cue. Any threshold below about 30 triggers on an empty room. Worse, a sweep passing through the cue's own frequency band reads about 70, so the detector could lock onto the measurement signal itself.
Two rules came out of that, and both still hold:
- Trigger only when the ratio exceeds 60 and the block energy is at least 30 times the scan's own noise floor.
- Never scan for cues mid-stream beyond the first match, because the sweep crosses the cue band and will false-lock on itself.
Attempt four: cancelling a latency that would not sit still
If every play's beep travels through the same reference channel, each sweep can anchor to its own beep and per-play latency cancels exactly. The arithmetic is sound. The cancellation worked. The numbers were still wrong — 70 to 85 ms of arrival error, while measured drift read 1.5 ms.
The reason is that a wireless receiver re-buffers at the start of every play, and the latency it introduces jumps by tens of milliseconds between one play and the next. Interpolating latency across plays is meaningless when the quantity being interpolated is re-rolled each time. Both reference plays were beautifully self-consistent, and both were lying.
Attempt five: the time itself was bending
Putting a beep on both sides of the sweep allows each play's true local rate to be measured from the spacing between them. This is where the investigation turned.
Offline dissection of the raw captures — the app exports the exact microphone WAV for precisely this purpose — showed the anchors matching a matched-filter reference to within 0.04 ms. Yet the same speaker, measured across plays, came out 2.7 ms apart.
The app was not misreading the time. The time was bending underneath it.
Wireless receiver software applies discrete resynchronisation jumps of roughly half a millisecond to nine milliseconds, at arbitrary points inside a single play — the equivalent of about 900 to 1500 parts per million. No anchor placed outside the sweep can correct for a jump that happens during it. The permanent rule: over a wireless link, never trust a fixed buffer-time interval. Measure it acoustically, on both sides.
| Attempt | Idea | What the bench showed |
|---|---|---|
| v3 | Anchor from a trigger beep | Detector fired on room noise; every anchor 2 s early |
| v4 | Reference-cue bracket, one per play | Latency cancelled, yet 70–85 ms of arrival error remained |
| v5 | Beep on both sides of the sweep | Anchors accurate to 0.04 ms; same speaker 2.7 ms apart across plays |
| v6 | Pilot bursts throughout the play | Anchor error 0 ms on three of four injected time jumps |
Attempt six: measure the clock continuously
The architecture that works stops trying to bracket the problem and instead measures it the whole way through. The amplifier's input is stereo with independent routing, so a train of quiet pilot bursts rides a fixed carrier channel for the entire play — including underneath the sweep on the other input. Every burst is a timestamp. A robust line fit across them reconstructs the receiver's actual time map, jumps and all, and the sweep's anchor is interpolated onto that map rather than onto an assumption.
The details that make it survive contact with a real room each cost a bench session:
- Bursts every 0.55 s at 12% of sweep amplitude, with a hole where the sweep crosses the burst band.
- A burst at a given moment deconvolves to a ghost earlier in the impulse response, so any burst whose ghost would land near the direct sound is never scheduled. That protects the frequency-response window, the region used for distortion analysis, and the peak search by construction — which is why no separate response sweep is needed.
- A dedicated burst locator with a tight symmetric window, because the general cue locator's wider window would grab the neighbouring burst at this spacing.
- Gains written once per play, so no control traffic disturbs the measurement mid-flight.
- Candidate alignments scored against the schedule's deliberately asymmetric exclusion hole, so burst identity is proven rather than assumed. Without it, a swallowed opening 100 ms made the detector lock onto the second burst and shift the entire timeline.
Validation, and the limit we publish
Injected faults are the honest test, because a real room cannot be told to misbehave on cue. Discrete jumps of −3.5, +4, −2 and +6 ms placed at 0.9 s, 3.2 s (mid-sweep), 4.9 s and 0.55 s produced anchor errors of −0.66, 0, 0 and 0 ms.
Against REW — the reference tool in this field — a wired measurement of the same system gave an inter-channel difference of +0.551 ms. The best wireless run measured +0.56 ms. That is agreement to 0.01 ms. Separately, the Xylem DSP's own delay block is accurate to 3 µs on a commanded 5.000 ms.
One code path serves both wired and wireless measurement. On a cable it simply measures a time warp of about zero.
What we do not claim
Accuracy is proven. Precision over a wireless link is limited by the receiver, and the app says so rather than hiding it: every run measures its own worst time warp and warns when it exceeds 0.5 ms, recommending a wired input for sub-millisecond work. A measurement tool that overstates its own certainty is worse than no tool, because the number it gives you is the one you act on.
There is one more reason this was solvable at all: we build the receiver. Where a third party would be stuck with whatever the far end does, the Air Mini runs on hardware we control, so the timing behaviour can be addressed at source as well as corrected in software.
The delay instrument described here is one of eleven in the XSCACE Studio calibration toolkit, which writes its corrections straight back to the Xylem DSP amplifier. The transport behaviour behind the timing jumps is documented in the wireless compatibility study, and the reverberation investigation that independently confirmed it is in Seven Releases to Measure One Number.
