What Éist's Android TTS Field Telemetry Can Tell Us

Éist collects on-device TTS health telemetry from installations with analytics enabled while synthesis is active. Analytics is enabled by default and can be turned off in Settings. The data is useful for finding questions worth investigating across the Android devices our listeners use. It is not a controlled benchmark, a representative survey of Android ownership, or a measure of every TTS implementation.

The event behind this work is called synthesis_health. Each row is a periodic active health sample, not one completed synthesis run. The samples record application performance signals such as the selected engine, average real-time factor (RTF), configured concurrency, reported device model, OS and app version. They do not contain book text, audio, or a person-level public identifier.

Éist is a free EPUB and PDF-to-audiobook app that synthesises narration on the device. That means the observations here describe Éist’s shipped configurations, analytics-enabled installations, and the conditions in which they use the app. They should not be read as a claim about all Android phones, all installations of Kokoro, or phone performance in a laboratory test.

What the telemetry measures

The standard benchmark metric for TTS is real-time factor (RTF): the number of seconds of processing time required to synthesise one second of audio. An RTF of 0.7 means the engine is faster than real time; an RTF of 1.3 means it is slower.

synthesis_health records an avg_rtf health signal while the app has active synthesis work. It is not a timed, fixed-text trial with a controlled thermal state, battery level, background workload, network condition or listening pattern. A sample is also not independent just because it is a separate row: a heavily used installation can contribute many more samples than a lightly used one.

The raw event stream is therefore a starting point, not publishable device rankings. Our reviewed aggregate snapshot filters test and emulator traffic, groups compatible app and runtime configurations, applies privacy floors, and makes the observation window explicit.

Why configured concurrency is not throughput

Configured concurrency matters when interpreting an application’s synthesis behaviour, but it is not a direct measurement of active worker utilisation or delivered audio duration. A tempting proxy is concurrency / avg_rtf; that proxy must be calculated at the right level of aggregation and independently validated against generated audio duration divided by elapsed wall-clock time before it is described as capacity or throughput.

We have not completed that validation for the field telemetry discussed here. For that reason, this article does not use configured concurrency to make throughput, playback-margin, full-book timing, or cross-platform capacity claims.

How the public snapshot is built

The Éist research snapshot reports only aggregates that pass both a 100 health-sample floor and a 10-installation privacy floor. It identifies the engine and exact shipped configuration, platform and OS band, observation window, app version, active health-sample count, and methodology version.

To prevent prolific listeners from dominating a cohort, the method first calculates an exact median for each installation within a comparable configuration and device cohort, then calculates exact percentiles across those installation-level values. Each installation gets one vote regardless of how many periodic samples it emitted.

The public table keeps RTF separate from any capacity proxy, excludes unsuitable rows, and states that the results are observational Éist field data rather than independent laboratory trials.

What this can and cannot answer today

The telemetry can help Éist detect regressions, identify device and configuration combinations that deserve a closer look, and decide where controlled testing is most valuable. The reviewed snapshot also documents the real conditions under which Éist’s own app is used.

It cannot, on its own, establish a phone’s maximum TTS performance, compare different engines fairly, predict a particular listener’s experience, or establish that one platform has a given throughput advantage. Those questions need controlled measurements or a separately validated aggregate method.

How we will publish the research

The Éist on-device TTS benchmarks hub is the canonical home for reviewed aggregate snapshots, methodology, exclusions and downloadable data. It distinguishes active health samples from individual synthesis calls, states the limits of the data beside each result, and cites immutable snapshot versions from related articles.

The responsible conclusion remains narrow: analytics-enabled field telemetry is valuable operational evidence for Éist, but it is not enough to support a general Android device ranking or throughput headline. No exact Android model cleared the 10-installation publication floor in the first snapshot, so Android is shown only at the broader engine-and-platform level.

Frequently asked questions

Q: Does Éist upload what I read to collect this telemetry?

No. The health telemetry described here concerns application performance and device context while synthesis is active. It does not include the text of books, articles or documents, or generated audio.

Q: Is this a benchmark of Kokoro or Android phones generally?

No. It is observational telemetry from Éist installations with analytics enabled and from Éist’s shipped configurations. It may surface hypotheses for controlled testing, but it does not establish general engine or phone rankings.

Q: Why not publish the raw event data?

Raw events can expose private or misleading detail, and repeated samples from one installation are not equivalent to independent trials. Éist will publish only privacy-reviewed aggregates that clear stated sample and installation floors.

Q: Where can I see the reviewed results?

The Éist on-device TTS benchmarks hub is the canonical source. It carries the methodology and immutable, versioned aggregate snapshot files.