Piper1 GPL: a local neural TTS engine that embeds espeak-ng for phonemization

The problem Piper1 GPL solves, and who ends up using it

Cloud TTS APIs charge per character and require a network round trip for every sentence. Piper1 GPL exists to remove both of those properties. The README describes it as "a fast and local neural text-to-speech engine that embeds espeak-ng for phonemization", which is a compact statement of the design: the neural model runs on your CPU and the text-to-phoneme step is handled by an embedded copy of espeak-ng rather than by a remote service.

The intended audience is visible in the README's list of users. Home Assistant uses it for spoken notifications inside a home automation setup. NVDA, the Windows screen reader, uses it to give blind and low-vision users a voice that does not depend on an internet connection. Open Voice Operating System, LocalAI and a Runelite plugin for Old School RuneScape are also listed. The common thread is software that needs to say something out loud on a machine the user already owns, often a small one. The related searches around Raspberry Pi text to speech and Linux TTS point at the same group: people running a Pi or a Linux box who want speech without sending text to a third party.

If you are building a commercial product that must keep its source closed, this is not the tool for you. The licence is GPL-3.0-or-later, and that is a deliberate choice by the Open Home Foundation, not an accident.

How the engine works: espeak-ng phonemes in, ONNX voices out

The pipeline has three stages. Text goes to espeak-ng, which is compiled into the package and shipped with its data directory; espeak-ng converts the text into a phoneme sequence. That phoneme sequence is what the neural voice model consumes. The voice model then produces audio.

The repository layout confirms how much is bundled rather than fetched at runtime. setup.py walks src/piper/espeak-ng-data and includes every file under it as package data, and it also packages per-language assets: an ONNX model and JSON id maps under src/piper/tashkeel for Arabic diacritics, nakdimon.onnx for Hebrew, and three TSV tables for Lithuanian. Those are not optional extras. They are installed with the wheel, which is why the package is larger than a thin client around a model download.

The build itself is a compiled extension, not pure Python. pyproject.toml declares scikit-build, setuptools, wheel, cmake and ninja as build requirements, and setup.py imports skbuild.setup. So pip has to compile C++ during installation unless a wheel matches your platform. The README links separate documentation for the CLI, the HTTP server, the Python API, the C/C++ API in libpiper/, training new voices, and building manually. That spread of interfaces is the real shape of the project: one engine, several entry points.

Installing piper-tts and speaking your first sentence

The README gives a single install command. It pulls a wheel when one exists for your platform and compiles from source otherwise, which is why the build toolchain in pyproject.toml matters.

pip install piper-tts

After installation the package exposes a command-line interface; the README links docs/CLI.md for its flags rather than listing them inline, so check that file for the exact arguments your version accepts. The HTTP server is the other quick way in. The project's Dockerfile builds a wheel from source in a python:3.12 builder stage, installs it into a python:3.12-slim runtime, adds Flask, and exposes port 5000 with docker/entrypoint.sh as the entry point.

docker build -t piper-tts .
docker run --rm -p 5000:5000 piper-tts

The container listens on 5000 once it starts. What you get from that endpoint, and the JSON shape of a synthesis request, is documented in docs/API_HTTP.md, not in the README. For embedding, the Python API is documented separately in docs/API_PYTHON.md, and the C/C++ surface lives in libpiper/. Voices are a separate concern from the engine: docs/VOICES.md is where the project points for the voice list, and the README links a samples page and a browser demo so you can listen before downloading anything.

Where Piper1 GPL is the wrong tool

The README carries a notice that the Open Home Foundation is looking for maintainers and gives [email protected] as the contact. That is the most important operational fact on the page. The repository is not archived and the last push was on 2026-09-17, with v1.8.0 released on 2026-09-04, so work is happening. But a project publicly asking for maintainers is telling you something about the bus factor, and you should plan for the possibility that voice coverage and bug fixes slow down.

The licence is the second constraint. GPL-3.0-or-later is a strong copyleft licence. Linking the engine into a proprietary application is not something you can do without legal review, and the README does not offer any alternative licensing path. The package metadata also notes that g2pW is Apache-2.0 and ships its own licence file, so the licence picture inside the distribution is not uniform, but the project as a whole is GPL.

Third, pronunciation is delegated to espeak-ng. That is what makes broad language coverage possible without a separate grapheme-to-phoneme model per language, and it is also why output quality depends on espeak-ng's phonemization for your language. The extra ONNX assets for Arabic, Hebrew and Lithuanian exist precisely because those scripts need handling that plain espeak-ng does not provide. If your language is not in the voice documentation, adding it means training a voice, and the README points to docs/TRAINING.md for that rather than promising it works out of the box.

How Piper1 GPL differs from a cloud TTS API

The obvious alternative is a hosted service such as the commercial TTS endpoints from the major cloud providers. The difference is not quality, which varies by voice and language, but where the computation happens and what you pay for it. A cloud API gives you a network dependency and a per-character bill; Piper1 GPL gives you a local process, no per-request cost, and a machine you have to size yourself. For a screen reader or a home automation hub that must keep working when the internet drops, that trade is the whole point.

A closer alternative is the original Piper project that this repository is the successor to. The name piper1-gpl and the GPL-3.0 licence indicate the split: this is the GPL branch of Piper maintained under the Open Home Foundation. If your constraint is licence compatibility rather than capability, that distinction is the one that decides which repository you pull from, and it is worth confirming against the project's own documentation before you commit to either.

Within the Python ecosystem, pyttsx3 is the other common local option. It wraps platform speech engines such as eSpeak, NSSpeechSynthesizer and SAPI5 rather than running a neural model, so it is lighter to install and produces more synthetic-sounding speech. Piper1 GPL's neural voices are the reason to accept the heavier build.

Maintenance, upgrades and what the GPL means for distribution

Upgrades follow normal Python packaging. The version in setup.py is 1.8.0, matching the v1.8.0 release on 2026-09-04, and the repository keeps a CHANGELOG.md at the top level, so the cost of an upgrade is reading that file plus re-running pip. Because the package bundles espeak-ng data and per-language ONNX models, a version bump can change the installed size as well as the code, and the build requirements in pyproject.toml mean a source install needs cmake and ninja present.

On licensing, the short version is that the package is GPL-3.0-or-later and that shipping it inside your own product triggers obligations that a permissive licence would not. The distribution also carries an Apache-2.0 component, g2pW, with its own licence file listed in setup.py's license_files. This is a description of what the repository states, not legal advice; if you are embedding the engine in a commercial product, that question belongs with a lawyer who can read COPYING and the licenses/ directory. The README's request for maintainers is the other cost to weigh: a project looking for maintainers may accept your patches, or it may not have anyone to review them.

Editorial conclusion

Adopt Piper1 GPL when you need speech synthesis that runs on your own machine and you can live with GPL-3.0 and with espeak-ng deciding pronunciation. Skip it if you cannot accept copyleft terms or if your language is not covered by the voices the project publishes. Before committing, check the VOICES documentation for your language, run the CLI once on your target hardware to hear the output, and read the CLI and Python API docs to see which interface fits your application.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. OHF-Voice/piper1-gpl on GitHub
4. README
5. Releases