tiny tts - Moses Yebei

The Problem

Most TTS models require hundreds of millions of parameters and GPU inference. TinyTTS fits a complete end-to-end English TTS pipeline into ~1.6M parameters and a ~3.4 MB ONNX model, targeting CPU-only edge devices and embedded systems.

What This Does

TinyTTS is a full text-to-speech stack: text normalization, grapheme-to-phoneme conversion, acoustic modeling, and waveform synthesis in one model. The Python package (tiny_tts/) handles training and inference; the npm-package/ directory offers pure Node.js inference via ONNX Runtime with zero Python dependency.

The repo includes ONNX exports (onnx/), a pre-trained checkpoint (checkpoints/G.pth), sample audio (samples/), and benchmark scripts comparing against Piper, Kokoro, and other small TTS models.

How It Is Wired

Execution starts at two entry points. The Python API path: synthesize_audio in app.py:19 reaches 19 functions, routing through speak in tiny_tts/__init__.py, which calls the model's infer method. The CLI path: main in benchmark_onnx.py:70 reaches 28 functions, routing through synthesize in tiny_tts/infer.py to the same model.infer call. Both paths leave the process in two hops: entry → synthesis function → model inference.

The module graph shows no circular dependencies across 30 internal modules and 47 import edges. tiny_tts/nn/__init__.py is the hub (7 importers, 0 dependencies); tiny_tts/utils/config.py similarly serves 6 importers. The widest blast radius sits in tiny_tts/nn/commons.py — its flatten_pad_shape is called from 7 places, insert_blanks from 4. tiny_tts/infer.py is the most unstable core module (instability 0.6), importing 6 modules while being imported by 4.

File responsibilities: tiny_tts/nn/modules.py owns the neural network layers (25 functions, 12 classes); tiny_tts/models/synthesizer.py builds the model (649 lines, 20 functions); tiny_tts/text/english.py handles phonemization (9 functions); tiny_tts/infer_onnx.py provides the ONNX inference path. The filesystem effects are minimal: benchmark.py and benchmark_onnx.py read/write files; no database or network calls exist in the traced paths.

How To Use It

# Python
pip install tiny-tts
tiny-tts --checkpoint G.pth --text "Hello world" --device cpu

# Node.js
npm install tiny-tts

Python API:

from tiny_tts import TinyTTS
tts = TinyTTS()
tts.speak("Hello, this is a test.", output_path="hello.wav", speed=1.0)

The ONNX model auto-downloads from HuggingFace on first npm use. Source installs require torch, torchaudio, soundfile, g2p-en, transformers, numba per requirements.txt.

Code Health & Issues

Static analysis found 8 issues (1 high, 7 medium). The high-severity finding: 21 duplicated 6-line code blocks across 6 files including tiny_tts/__init__.py, tiny_tts/infer.py, and tiny_tts/models/synthesizer.py — extract shared helpers. Medium findings: deep nesting (depth 6) in tiny_tts/models/synthesizer.py and tiny_tts/alignment/core.py; synthesizer.py at 649 lines; setup.py opens files without context managers.

SDLC gaps: no test suite across 30 source files, no CI configuration, no lockfile (npm), and three large binaries (19.1 MB checkpoint, 14.1 MB and 13.8 MB ONNX files) committed directly. A license file exists; no secrets were found.

The Bottom Line

TinyTTS is a genuinely small, working TTS model with clean module boundaries and no circular dependencies. The missing test suite and CI are the main risks for anyone extending it. Use it for CPU-constrained or embedded TTS where a 200 MB model is unacceptable; skip it if you need production-grade reliability guarantees.

What the analyser found

Deployment readiness

3/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

57 files

Python26
JavaScript3
JSON3
Markdown2
TypeScript1
TOML1

ReactFlaskPyTorchONNX

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["tiny_tts<br/>21 modules"] g1["(root)<br/>5 modules"] g2["npm-package<br/>4 modules"] g1 -->|11| g0

Module dependencies

The 10 most depended-upon modules of 30, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_tiny_tts_nn___init__["__init__"] n1_tiny_tts_text___init__["__init__"] n2_tiny_tts_utils_config["config"] n3_tiny_tts_infer["infer"] n4_tiny_tts_text_english["english"] n5_tiny_tts_text_symbols["symbols"] n6_tiny_tts_models_synthesizer["synthesizer"] n7_tiny_tts_nn_commons["commons"] n8_tiny_tts___init__["__init__"] n9_tiny_tts_infer_onnx["infer_onnx"] n8_tiny_tts___init__ --> n4_tiny_tts_text_english n8_tiny_tts___init__ --> n1_tiny_tts_text___init__ n8_tiny_tts___init__ --> n0_tiny_tts_nn___init__ n8_tiny_tts___init__ --> n6_tiny_tts_models_synthesizer n8_tiny_tts___init__ --> n5_tiny_tts_text_symbols n8_tiny_tts___init__ --> n2_tiny_tts_utils_config n8_tiny_tts___init__ --> n3_tiny_tts_infer n3_tiny_tts_infer --> n4_tiny_tts_text_english n3_tiny_tts_infer --> n1_tiny_tts_text___init__ n3_tiny_tts_infer --> n0_tiny_tts_nn___init__ n3_tiny_tts_infer --> n5_tiny_tts_text_symbols n9_tiny_tts_infer_onnx --> n4_tiny_tts_text_english n9_tiny_tts_infer_onnx --> n1_tiny_tts_text___init__ n9_tiny_tts_infer_onnx --> n0_tiny_tts_nn___init__ n9_tiny_tts_infer_onnx --> n2_tiny_tts_utils_config n6_tiny_tts_models_synthesizer --> n0_tiny_tts_nn___init__ n6_tiny_tts_models_synthesizer --> n7_tiny_tts_nn_commons n6_tiny_tts_models_synthesizer --> n1_tiny_tts_text___init__

Findings

MediumNo test files detected - untested code paths repository-wide
MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
LowDependencies declared without a lockfile - non-reproducible builds npm-package/package.json

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high3

medium2

low1

Add a test suite; this repository has nonehigh30 occurrences

30 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Commit a lockfile beside the manifesthigh

npm-package/package.json

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Add a workflow that builds and tests this repositoryhigh

30 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Move large binaries to Git LFS or out of the repositorymedium5 occurrences

checkpoints/G.pth

5 blobs over 5MB: G.pth 19.1MB, flow.onnx 14.1MB, decoder.onnx 13.8MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.