🍓 Piper TTS: Fast Offline Voice Synthesis on a Raspberry Pi

Piper is the text-to-speech half of the local voice stack small enough to run in real time on a Raspberry Pi with no GPU, which is the entire reason it exists instead of everyone just pointing at Kokoro. Different hardware target, different job.

I keep a Pi 5 on the desk specifically for testing stuff like this, next to the RTX 4080 that handles everything that actually needs a GPU. Piper never touches the 4080. That's the whole pitch.

By the numbers

• pip install piper-tts is the entire install command, currently sitting at version 1.6.0 on PyPI as of July 23, 2026. Actively maintained, not abandoned
• The original rhasspy/piper repository went read-only in October 2025; active development moved to OHF-Voice/piper1-gpl under the Open Home Foundation, and the license changed from MIT to GPL-3.0 along the way
• Synthesizes in real time on a Raspberry Pi 5, CPU only, no accelerator
• One CPU benchmark clocks Piper at a real-time factor around 0.192, roughly 5x faster than the audio it's generating; short-sentence inference on a Pi 5 has been measured as low as 0.54 seconds
• 30+ languages and dialects, 100+ voices, all distributed as ONNX files on Hugging Face across four quality tiers: x_low, low, medium, high
• Piper embeds espeak-ng for phonemization, so pronunciation of unusual or foreign words leans on espeak's rules rather than a learned model, the one place quality still occasionally slips

What changed in the Piper project

Most tutorials still link the old rhasspy/piper repo and the MIT license that came with it. That repo is read-only now. The project's actual home is OHF-Voice/piper1-gpl, it's GPL-3.0, and the pip install piper-tts command still works the same either way because PyPI tracks the new maintainers. The license swap matters for exactly one group of people: anyone folding Piper into closed-source commercial firmware, who now has a copyleft license to deal with instead of a permissive one. Everyone else won't notice a thing changed.

Installing on a Raspberry Pi

python3 -m venv piper-env
source piper-env/bin/activate
pip install piper-tts

A virtual environment isn't optional advice here — Raspberry Pi OS's system Python is externally managed and will refuse a bare pip install outright. Pull a voice model next (the VOICES catalog on the project's Hugging Face page lists all of them). Each voice is two files, a .onnx model and a matching .onnx.json config, and both need to sit in the same folder or Piper won't find the one it needs. Then synthesize:

echo "Testing on the Pi." | piper --model en_US-lessac-medium --output_file test.wav

That's the entire path from a blank SD card to a spoken sentence, no cloud account, no API key.

One Pi-specific snag worth flagging: a headless Pi sometimes defaults audio output to the wrong device, HDMI instead of the 3.5mm jack or a USB DAC. aplay -l lists what Linux actually sees, and raspi-config's audio menu picks the right one — a five-minute fix that isn't Piper's fault but gets blamed on it constantly in forum threads.

Choosing a voice quality tier

Tier	Sounds like	Realistic on
x_low / low	Clearly synthetic, very light	Pi Zero 2 W, anything CPU-starved
medium	Good enough that most listeners stop noticing	Pi 4 (a little strained), Pi 5 (comfortable)
high	The best Piper gets	Pi 5 only, and it's still not a huge leap over medium

Medium is the tier that actually matters. It's the point where a visitor stops asking "is that a robot" and just listens, and it's the highest tier a Pi 5 runs without drama.

Pi 4 vs Pi 5: what actually changes

A Pi 5 handles medium-quality Piper in real time without complaint. A Pi 4 gets there too on lighter voices, but medium and high-quality models introduce a delay of a couple of seconds per sentence — noticeable, not broken. If a project is Pi 4-only for cost or stock reasons, x_low or low is the tier that keeps things feeling instant instead of laggy. If it's Pi 5, medium is free money: better quality, same real-time feel.

Using it directly in Python

Piper doesn't require a Wyoming server or Home Assistant at all. The Python API works standalone for any project that just needs a function call that returns audio:

from piper import PiperVoice

voice = PiperVoice.load("en_US-lessac-medium.onnx")
audio = voice.synthesize("Testing straight from Python.")

That's the whole thing for a maker project that never touches Home Assistant: a doorbell announcer, a talking sensor, a museum kiosk, anything that just needs one script and one voice model minding its own business.

When Piper isn't the right pick

Piper doesn't clone voices, and it isn't trying to. For a desktop project where CPU headroom isn't the constraint, Kokoro is the better-sounding pick for roughly the same effort. Cloning one specific person's voice from a sample is a different job entirely, and the three-way comparison against Chatterbox and XTTS covers that ground. If the goal is a full voice assistant rather than just narration, Piper is only the TTS half of the Home Assistant pipeline — the piece that talks back, not the whole system.

Piper is one file, one model, and no dependency on anything with a fan. Running a neural voice at all used to mean a cloud API and a network round-trip; now it's a Pi Zero and a Python script minding its own business in a closet.