Every number, with what we saw

The page's promise is the best figure the app has measured, marked with an asterisk. This page is the whole record behind it: each figure names the day, the speakers, the instrument, and the build the app measured it on. One room and the speakers named. Where the record has no number, this page says so.

The promise and its asterisk

The page says the array holds wired and Ethernet speakers to about a millisecond. That figure is the Raspberry Pi's, on Ethernet, measured on 20 October 2026. Wired speakers share one clock inside the array and have no figure of their own to drift. Bluetooth speakers are different, and the Bluetooth section below says how.

A Raspberry Pi over Ethernet

The Mac tells the Pi when to play each sound, and the Pi reports how far off it was. The number is the Pi's own servo error, read from the app at two samples a second; no microphone is involved. The capture is published at /data/sync.json.

• 20 October 2026, from 23:02, on the 0.2 development build, three speakers playing (a JBL Flip 7 over USB, the MacBook Pro's speakers, a Samsung Q700C soundbar through the Pi over Ethernet): one capture of 1,037 samples over 522 seconds, 0.272 ms on average, the largest 0.297 ms. Its first 193 samples averaged 0.271 ms, the largest 0.294 ms. The home page's "about ±0.3 ms" is the average of its last 20 seconds, 0.278 ms.
• The home page writes it with a ± because the Pi holds a ±0.3 ms deadband; every reading in the capture was positive, 0.088 to 0.297 ms.
• Over Wi-Fi: no long run in the record yet. A Pi on Wi-Fi joins and is graded by its own lock every second; its figure will appear here when it has been measured.

What we saw: the Pi holds its deadline inside its band by design. The figure leaves out the Mac-to-Pi clock mapping and the soundbar's own delay; it is a report from the Pi, not a sound measured in the room, and the room measurement for this path is still owed.

Wired, USB and the Mac's own speakers

They share one clock inside the array, so they cannot drift apart. The only figure is the one-time alignment the microphone makes.

• 18 October 2026, on the 0.2 development build: the microphone timed a USB JBL Flip 7 at 57 ms after the MacBook's own speakers, and the array holds that offset; the capture of 20 October published at /data/sync.json carries the same figure as the Flip's arrival. How closely the alignment lands is not in the record yet.

What we saw: nothing to track over time. A wrong alignment would be a fixed offset, and the microphone removes it.

Bluetooth speakers

Measured with one JBL Flip 7 and the MacBook Pro's microphone on 1 and 2 November 2026, on development builds of 0.6 unless a line says otherwise. 0.6 is the public download from 2 November 2026; it carries the start-time chirp, the 44.1 kHz fix and the measured video figure described below. The 0.5 download before it compensated a Bluetooth speaker from the delay macOS reports and set it to 48 kHz, the fault described below.

• macOS reports the Flip's delay as 233.2 ms; the speaker itself reports 200 ms. The microphone hears it 494 to 501 ms after the array renders it on most readings, 475 to 538 ms across the two days, the microphone's own delay included. After each start's correction the two speakers landed within 9 ms of each other, within 1 ms on eight of sixteen starts.
• About 300 ms of the path is in neither the app's model nor what macOS reports, and both speakers' paths include it: the measured path minus the delay the app itself applies to the Mac's speakers came to 301.5 ms at each of three captures on 1 and 2 November, and 302 ms measured directly at 12:53 on 2 November. Whether it comes with the Bluetooth speaker is not yet measured; the app only runs this measurement when one is playing.
• At each start a short chirp times the Flip against the Mac. On nineteen starts the first pass moved it by 4 to 91 ms. A second pass about forty seconds later found the first pass's figure right within 1 ms on seven of sixteen starts and corrected it by 2 to 23 ms on the rest; the landing figures in the first bullet are what the last pass of each start found. From 2 November 12:08 a start begins from the remembered figure; the first passes since then moved it 4, 12, 22, 23, 24 and 27 ms, and 91 ms once, at 12:53, the first start after the afternoon fix dropped the trim the ratchet had left on the Mac's speakers.
• Across the two days the chirp was heard at a signal-to-noise ratio of 26 to 668 on the Flip and 97 to 3,306 on the Mac's speakers; a Bluetooth reading counts from 15.
• Between chirps the app listens for a quiet pilot tone from each speaker. The pilot never moves a Bluetooth speaker; when it hears the Flip 25 ms or more off twice, the app chirps again, 43 times between the evening of 1 November and 12:58 on 2 November. Between 10:00 and 11:29 on 2 November the Flip's reading came by the pilot tone in 192 of 865 listening cycles; 214 cycles heard nothing from it, and 216 readings fell below 450 ms, where the sound cannot have arrived.
• On that morning those readings did harm by a side door. Through the tracker's clock filter they taught the Mac's own speakers a false drift of about 14 ms every three minutes, 17 at its fastest, from 0.5 ms to 261 ms between 10:00 and 11:12. Fourteen chirps then shortened the Flip's planned path to hide it, 196 ms down to zero, and once it reached zero the Mac's speakers ran 24 to 104 ms late for 55 minutes, until a restart at 11:51. From the afternoon of 2 November the app keeps a Bluetooth speaker's readings out of that filter entirely, and a single wired speaker is no longer trimmed against anyone. A chirp the pilot asked for that finds the speaker within 10 ms of its plan counts as a false alarm; after two in one run, the pilot must agree twelve readings in a row and wait ten minutes before it can ask again. 0.6 carries all three.
• 1 November 2026, the fault behind the slowed, ghostly sound: macOS offered the Flip at 48 kHz while its Bluetooth link ran at 44.1 kHz, and the app set 48 kHz at every start, so a 1,000 Hz tone played at 915.6 Hz, a semitone and a half flat. 0.5 did this. 0.6 runs a Bluetooth speaker at 44.1 kHz and puts the rate back within one listening cycle, about five seconds, when CoreAudio pushes the array's 48 kHz onto it.
• Video, on the development build until 2 November: the Mac's players were told 222 ms while the sound arrived about 500 ms after it was rendered, so by the app's arithmetic the picture ran about 300 ms ahead, about 400 ms by the owner's eye. The 0.5 download told them the delay macOS reports plus its buffer, 255 ms on 1 November. 0.6 measures the whole path at the first start and remembers it for that speaker. It tells the players the measured figure: 500 ms at 12:53, which the next pass found 22 ms short, then 523 ms at 15:20 and 516 ms at 15:27. Checked by eye on 2 November with a YouTube clip: the lips match; the owner puts what remains at about 10 ms.
• 2 November 2026, 15:20 to 16:04, three speakers on 0.6: the MacBook's own, the Flip over Bluetooth, and a Samsung Q700C soundbar over Bluetooth from 15:26. The Mac's own speakers kept a trim of 0.0 ms through all 458 listening cycles. At the first start the three chirps heard the Flip 475, 488 and 495 ms after rendering; after the restart that admitted the soundbar, 518, 517, 499 and 507 ms; at the re-measure half an hour later, 500, 508 and 495 ms. The soundbar's first pass did not hear it; the six after heard it between 470 and 524 ms, and the last of them set its path 38 ms shorter than the pass before. One re-measure was asked in 44 minutes; its first pass found both speakers 7 ms from their plan, the first false alarm on the afternoon's count. The pilot tone was heard from the soundbar in 307 of 405 cycles and from the Flip in 11 of 458.

What we saw: the owner hears a small but noticeable mismatch at times. The morning of 2 November showed one cause in the record, described above, and 0.6 carries the fix; the afternoon showed two more, the first minutes' settling and a soundbar's wander between chirps. Neither is fixed in 0.6.

A Samsung TV as a web speaker

A probe on 3 September 2026, not a feature of the app: a Samsung UA43TU (Tizen 5.5) driven as a browser receiver, on the earlier MacBook Air, timed by an Android phone's microphone.

• From schedule to sound, 416 ms on average, about 370 ms of it the TV's own depth; standard deviation 6.6 ms, 95th percentile 427 ms, over 358 clicks in 13 minutes.

What we saw: usable only where the TV is the room's only speaker. Beside a soundbar its wander would be heard.

What these figures are not

• Not averages over many rooms or many speakers. One room and the speakers named above; the TV probe ran on the earlier MacBook Air with a phone's microphone, everything else on the MacBook Pro.
• The microphone's own input delay sits inside the Bluetooth path figures, and its size is not measured. It cancels between speakers, because every speaker is heard by the same microphone, but not in the video figure.
• Not a promise about your room. The app measures yours and shows its own numbers in the Tune panel.

The record behind this page is the developer's log, with its dates in Indian Standard Time. Write to hello@acousticorbit.com if a number here does not match what you see.