Multilarm publishes measured performance figures from its own production hardware. On a Raspberry Pi 400, neural speech synthesis runs at a real-time factor of 2.14, a cold announcement starts speaking in about 5 seconds, the cloud round trip is 21 milliseconds, and an audio sequence adds 14 milliseconds between files. Every figure states its method, hardware and date.
Most software in this category publishes no performance figures at all, which leaves a buyer comparing marketing adjectives. This page is the opposite: every number below was measured on real hardware, and each one states what was measured, on what, when, and how. Where the honest number is unflattering it is still the number — a benchmark you only publish when it looks good is an advertisement, not data.
Everything here may be quoted and cited. Please cite the URL of this page and the measurement date, because these figures move as the software changes.
Unless a row says otherwise, the device is a Raspberry Pi 400 — a 1.8 GHz quad-core Cortex-A72 (ARMv8.0-A, 4 GB RAM) running Raspberry Pi OS 64-bit. It is the reference device because it is the cheapest thing that runs the whole stack including neural speech, and because it is the machine in day-to-day production use, not a lab rig. Anything measured against the cloud service was measured over an ordinary domestic broadband connection in the United Kingdom.
Synthesis on a Pi 400 runs at a real-time factor of about 2.1 — roughly two seconds of computation per second of speech produced. That is the measured floor for this model on this class of processor, not a provisional figure: four model variants were built and benchmarked on the device itself, and the one shipped is the fastest that still sounds correct.
| Model variant | Warm real-time factor | Size | Outcome |
|---|---|---|---|
| uint8 (shipped) | 2.14 | 177 MB | Fastest that is correct |
| fp32 | 2.49 | 325 MB | ~15% slower and 1.8× larger |
| int8 dynamic | ~5.0 | 92 MB | ~2× slower on ARM |
| int8 static QDQ | not measurable | — | Quantisation corrupts the output |
Measured 2026-06 on a Raspberry Pi 400, warm cache, a medium-length line of 95 characters, using the bundled Kokoro 82M ONNX model under ONNX Runtime.
The reason it cannot go faster is worth stating plainly, because it is the kind of claim that is usually hidden: profiling showed about half the inference time is convolution and matrix multiplication and the other half is vocoder work — transcendental functions, short-time Fourier transforms, elementwise maths — that no quantisation or execution provider accelerates. The Pi 400's Cortex-A72 is ARMv8.0 and has no dot-product instruction, so the usual int8 win is unavailable. A newer board with ARMv8.2 or later would change this result.
No, and the distinction matters. Real-time factor measures synthesis, and the figure a listener experiences is time to first audio, which is a different number because speech is produced in clauses and cached.
| Measurement | Value | Method |
|---|---|---|
| Time to first audio, cold, before optimisation | ~28 s | Full-utterance synthesis before clause splitting |
| Time to first audio, cold, current | ~5 s | Clause-split streaming, first clause plays while the rest synthesises |
| Repeated or pre-warmed line | 4.15 s, from 13 s | Measured on the Pi: disk cache hit after keystroke-triggered pre-warm |
Measured 2026-06 on a Raspberry Pi 400. Scheduled announcements are unaffected by any of this — they are synthesised ahead of their fire time, so the audio is already on disk when the moment arrives. These figures apply to speech typed ad hoc into the dashboard.
The cloud service does not connect inward to a building. Devices poll outward over HTTPS, which is why no firewall port has to be opened, and it is also what sets the latency floor.
| Measurement | Value | Method |
|---|---|---|
| Cloud server round trip from the device | 21 ms | Device self-test D-D01, measured 2026-08-15 on the production Pi |
| Status push interval | 30 s | Fixed interval, plus an immediate push after any command |
| Command poll interval | 5 s | Falls back exponentially to 60 s while the network is unreachable |
| Audio sequence per-item open cost | 14 ms | Measured on the Pi 2026-08-01 against a 150 ms budget |
The 14 ms figure is the one to look at if you care about timing precision: it is the gap the device adds between two files in a scheduled sequence, on top of the silence you asked for. A bell that must land on the minute lands on the minute.
Background music needs a library behind it, and a library is only useful if scanning it is not an event. These figures come from the production Raspberry Pi 400 over the device API in September 2026, against 492 audio files totalling 1.3 GB.
| Measurement | Value | Method |
|---|---|---|
| Full cold scan, 492 files / 1.3 GB | 4113 ms | First scan of the folder, tags read from every file, 2026-09-13 |
| Re-scan with nothing changed | 1088 ms | Incremental pass; files matched on size and modification time |
| LAN listen stream, per listener | 1.54 Mbit/s | 2,296,364 bytes for 11.96 s of 48 kHz 16-bit stereo PCM |
The incremental figure is the one that matters day to day: a scheduled re-scan of an unchanged library costs about a second, so it can run often enough that a track dropped into the folder this morning is available this afternoon. The cold number is published rather than the warm repeat (3127 ms) because the first scan is the one a new installation actually experiences. On the listen stream, 1.54 Mbit/s per listener means the 32-listener ceiling is roughly 49 Mbit/s of LAN traffic - comfortable on a wired network, worth thinking about on wifi. A 44.1 kHz source gives 1.41 Mbit/s instead.
| Measurement | Value | Method |
|---|---|---|
| Distinct self-test checks on the device | 39 | Deployment, clock and schedule, audio, cloud and network, hardware |
| Features audited against production hardware | 156 | Full feature audit, 2026-08-03 |
| Result of that audit | 148 green, 8 amber, 0 red | Live run against the production Pi 400, not a local stub |
The eight amber results were probes that could not complete because the hardware they need was not attached — a relay board and a working microphone on that device — rather than features found broken. Zero red.
| Item | Typical cost |
|---|---|
| Raspberry Pi 400 or equivalent single-board computer | £60–£100 |
| USB or 3.5 mm audio output to your existing amplifier | £0–£15 |
| Multilarm licence, charity tier | £99 one-off |
| Multilarm licence, up to 50 devices | £945 one-off |
| Personal, non-commercial use | Free |
| Optional cloud dashboard | Billed monthly, optional |
Licences are perpetual, not subscriptions — a point worth stating precisely because it is the fact most often got wrong about this software. The only recurring charge is the optional cloud relay, and the system runs entirely without it. It also runs on a Windows or Linux PC you already own, in which case the hardware line is zero.
Three things are missing from this page on purpose, and saying which is part of making the rest trustworthy: audio quality, comparisons against named competing products, and any figure from hardware not owned and tested here. Each is explained below.
The device self-test that produces the latency and audio figures runs on any installation: Multilarm --diagnose prints all 39 checks with their measured values. The speech benchmark is a bundled tool. If you measure something materially different on comparable hardware, that is worth telling us about — the numbers here are what we observed, not a claim about every device.
The standards and primary sources behind the claims on this page are listed below.