Palash Debnath
5cab8e0149
Renames what users see. The app, the installers, the window title, the
docs and all 21 locales now say VoiceStudio, with "(previously
OmniVoice-Studio)" noted near the title of each doc surface so people
recognise it.
Deliberately NOT renamed, because renaming any of them silently breaks
an existing install — there is no legacy-path fallback anywhere in this
codebase:
- bundle identifier com.debpalash.omnivoice-studio (MSI UpgradeCode,
macOS TCC grants, managed venv, WebView localStorage, the
single-instance lock)
- data directories OmniVoice / .omnivoice and omnivoice.db
- the ~150 OMNIVOICE_* environment variables
- the X-OmniVoice-* HTTP headers (a wire protocol)
- the published Docker image paths
- the OmniVoice ENGINE, which is a model name and not this product
tests/test_identity_paths_survive_the_rename.py pins every one of those
so a future well-meaning sweep cannot orphan a user's library.
Linux .deb users install a new package name and should apt remove
omnivoice-studio; that note is in the changelog.
3.3 KiB
Adding a TTS or ASR engine
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.
The job map
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 |
| 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.
The bar
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, no ambiguous provenance. This is the one that most often ends a proposal, so check it first.
- 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.
Deprecation
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.
If it doesn't clear the bar
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.