VoiceStudio ships a lot of engines. That breadth is only an asset while every one of them still works on every platform — otherwise it is a pile of support queues, and the project's actual promise (a first run that works) is what pays for it.
So new engines are hired for a job, not added to a list.
Every engine in the tree owns at least one job. A job has exactly one holder.
| Job | Held by |
|---|---|
| Best zero-shot clone quality | omnivoice |
| Widest language coverage | omnivoice |
| Crash isolation for the default model | omnivoice-subprocess |
| Fastest CPU render / lowest latency | open — see #1306 |
| Best Chinese/Japanese expressiveness | cosyvoice, indextts2 |
| CPU-realtime English, tiny footprint | kittentts, supertonic3 |
| Bilingual reference-free voice design and direction | audiocpp |
| Best transcription accuracy | whisperx, faster-whisper |
| Fastest Apple-Silicon transcription | parakeet-mlx, mlx-whisper |
| Crash isolation for transcription | faster-whisper-isolated |
A proposal must either take a job from its current holder (with numbers) or claim a job nothing covers. "It benchmarks well" is not a job.
A new engine is accepted when all of these hold. Miss one and the answer is no — which is a property of the bar, not a judgement of the contributor.
- A job, named. Which row above it takes or adds, and why the incumbent does not cover it. Latency, language, hardware envelope or quality tier — something a user would choose it for.
- Licence clean for commercial use. Model weights and code. No
research-only weights or ambiguous provenance. The single approved
exception is
audiocppwith Breeze-TTS-2 research/non-commercial weights, approved by the owner on 2026-09-08 for its requested bilingual voice-design and direction workflow. It remains opt-in and discloses the restriction before selection and download;@debpalashis its named steward. - Every platform, or explicitly opt-in. macOS (Apple Silicon and Intel), Windows, Linux. A CPU path is required — an engine that only runs on one accelerator is fine, but it must degrade rather than break, and a platform-only engine goes behind an opt-in (see CLAUDE.md's parity rule).
- Fits the existing adapter.
TTSBackend/SubprocessBackendwith no changes to core pipelines. A dependency profile that conflicts with ours means a sidecar (SubprocessBackend), which is a solved shape — seedocs/engines/omnivoice-subprocess.md. - A CI smoke test in the same PR. It does not need a GPU: stub the sidecar, assert the adapter contract. An integration with no test is an integration nobody will notice breaking.
- A named steward. The proposer commits to being the point of contact for that engine's issues for 12 months. No steward, no merge — this is the difference between breadth and debt.
- Demand evidence. A real request, a real workflow, a real user. Ideally someone already working around its absence.
Breadth is only worth carrying while it is alive. An engine is archived when, for two consecutive releases, it has no steward and no passing smoke test. Archiving is not a judgement either — it is how the remaining engines stay trustworthy.
The adapter interface is public. An engine can live out-of-tree, be installed alongside, and be selected by id — you do not need our merge to use your engine, and we would rather link a good external engine than carry a half-maintained internal one.