Piper Review After 6 Months: Running Local TTS in Production

I set up Piper in my homelab six months ago as a replacement for cloud-based text-to-speech. The promise was simple: fast local speech synthesis, no API costs, no data leaving the network. After half a year of actual use—not just testing—I’ve got a clearer picture of what this tool does well and where the cracks show.

What Piper Is and Why I Installed It

Piper is a neural text-to-speech system from the Rhasspy project. It runs on CPU, requires no GPU, and produces speech in dozens of languages and voices. Home Assistant uses it for local voice responses. The appeal is obvious if you’re running a homelab: generate speech locally, keep data internal, avoid subscription costs.

My setup is straightforward. I run Piper in Docker on a Proxmox VM with two CPU cores and 2GB RAM allocated. It sits behind a simple API endpoint. Home Assistant calls it when automations need to speak. A few other services tap into it too—mostly for status announcements and alerts.

Installation was friction-free. The official Docker image just works. Configuration is minimal. After that, the real story begins.

The First Three Months: Actually Impressive

Initial performance surprised me. Latency was genuinely low—sub-second for short sentences. The quality of the synthesized speech was better than I expected from a CPU-based tool. I picked the en_US-amy-medium voice and it sounded natural enough that automation responses didn’t feel robotic or uncanny.

The CPU usage was flat. Even during concurrent requests, the VM never spiked past 40 percent. I wasn’t worried about resource contention. The audio files generated were small and cacheable. I wrote a simple wrapper script to cache TTS output by hash, so repeated announcements (like “motion detected”) played from disk instead of regenerating.

Multilingual support worked. I tested German and Spanish voices without any setup complexity. Just pass the language code and model name. The quality dropped slightly compared to English, but it was still acceptable for automated messages.

For the first quarter, Piper felt like a solid win. No cloud dependency. No recurring costs. Good enough quality.

Where Things Got Annoying: Months 4 and 5

Then I hit the first real problem. I was testing concurrent TTS requests—maybe five or six simultaneous API calls—and noticed some responses were timing out. The requests themselves weren’t failing, but synthesis was taking 3–5 seconds instead of 200 milliseconds. Piper was queueing requests sequentially instead of handling them in parallel.

This is a known limitation, not a bug. Piper’s inference engine is single-threaded. If you care about high concurrency, you need to either run multiple instances or accept that simultaneous requests will serialize. I didn’t care enough to set up multiple containers, so I just added a request queue with a 10-second timeout in my wrapper. It mostly works, except when automations fire in bursts.

The second annoyance was more of a surprise. A Piper update—I wasn’t paying attention to which version—changed voice model names. My docker-compose file referenced en_US-amy-medium, which suddenly didn’t exist. The new version wanted en_US-amy-medium-glow-tts or something similar. I had to hunt through GitHub issues to figure out which model was the actual replacement. Documentation didn’t mention the breaking change.

This knocked Piper offline for a couple of hours. Not catastrophic, but it made me realize I should version-lock the Docker image instead of running latest. I did that immediately.

Then there was the voice quality regression. Around month five, I swapped to a different voice model (en_US-lessac-medium) to test variety. It sounded noticeably worse than what I remembered from Amy. Harder consonants, less natural phrasing. I switched back. No harm done, but it suggested that not all voices are created equal. You need to test the specific voice you pick. The GitHub docs don’t really tell you which voices are “good” versus “acceptable.”

Latency and Real-World Use

In controlled tests, Piper synthesizes a 10-word sentence in 150–250 milliseconds. In production, you rarely see that. Network round-trip time, JSON parsing, audio file I/O, and my wrapper’s caching logic all add overhead. A typical end-to-end flow—Home Assistant sends request, Piper generates, response comes back, audio plays—takes about 800 milliseconds to 1.5 seconds on my network.

That’s fast enough for most homelab uses. For something like a voice alert or notification, latency under a second is fine. If you were building a real-time voice chat interface, you’d need something else.

What surprised me is that latency isn’t consistent. Sometimes the same request takes 300ms, sometimes 1.2 seconds. I haven’t figured out why. Maybe kernel scheduling on the Proxmox host, maybe the audio file I/O varies. I’ve learned not to rely on Piper for time-critical responses.

CPU and Memory Reality Check

Piper advertises “low CPU usage.” That’s technically true, but the claim needs nuance. Idle, the process uses almost nothing. When synthesis happens, it spikes—usually 60–80 percent of one CPU core for the duration of synthesis. If you’re running on a single-core machine or a Raspberry Pi Zero, that spike is noticeable. On a modern CPU, you barely notice it.

Memory usage is stable. The process sits at 200–300MB regardless of how much synthesis happens. No memory leaks that I’ve caught in six months. If you’re constrained on RAM, Piper is one of the least demanding services in your lab.

docker stats piper
CONTAINER ID  NAME      CPU %     MEM USAGE / LIMIT
abc123def456  piper     0.2%      245M / 2G

That’s idle. During a synthesis request, CPU jumps to 70–75 percent for 200–400ms, then drops back.

The Thing About Caching and Voice Quality

Caching TTS output is obvious in theory. Same text, same voice, same audio—why synthesize twice? But I noticed something: the cached audio sounds different when it plays back months later, especially after system reboots or when played from different devices. This isn’t Piper’s fault. It’s just audio playback variance, but it made me question whether I should cache aggressively or just let Piper regenerate.

I settled on a 7-day cache TTL for non-critical announcements and no caching for alerts. It’s a compromise.

The bigger realization was that Piper’s voice quality is decent but not great. It’s not bad—it’s completely usable for homelab purposes. But if you’ve listened to modern cloud TTS (Google, Amazon), Piper sounds like a step down. Less emotional inflection, occasional weird prosody, less natural phrasing. No show-stoppers for automation messages, but noticeable if you’re paying attention.

Stability and Maintenance Over Time

In six months, Piper has crashed exactly once. That was my fault—I misconfigured the Docker memory limit and the OOM killer got it. Since then, it’s been rock-solid. No hangs, no memory leaks, no weird edge cases in the logs. Just runs.

Updates are rare and painless. The Rhasspy team doesn’t push changes constantly. When I do update, it’s usually a minor version bump that doesn’t break anything if I keep my configuration stable.

Logs are mostly quiet, which is good. The only persistent message is a startup note about which models are loaded. No spam, no warnings about deprecated stuff.

Would I choose Piper again if I were starting over? Yes, but with adjusted expectations. It’s not a cloud TTS replacement for every use case. It’s a solid local option that trades some voice quality and concurrency for zero cloud dependency and low resource use. That trade works fine for a homelab. For anything customer-facing or where voice quality matters, you’d want something else.

FAQ

Can Piper run on a Raspberry Pi?

Yes, but with limitations. It runs on older Pi models (Pi 3, Pi 4) without GPU. Synthesis is slower than on x86—expect 500ms–2 seconds for a short sentence depending on the Pi generation. A Pi 5 or newer with more CPU cores is more practical.

How much RAM does Piper need?

Piper runs in 256MB minimum, though I’d recommend 512MB to 1GB for stable operation with concurrent requests. The process itself uses 200–300MB, and system overhead takes the rest.

Does Piper need a GPU?

No. Piper is CPU-only. You don’t need CUDA, OpenCL, or any GPU drivers. This is one of its main advantages for homelab use on older or lower-end hardware.

How do I choose which voice model to use?

Test multiple models before committing. Quality varies significantly between voices even within the same language. Download a few, generate test audio, and listen. The GitHub repository lists all available models with language and gender labels, but you have to judge sound quality yourself.

Does Piper handle concurrent requests well?

Not really. Synthesis is single-threaded, so multiple simultaneous requests will queue. For most homelab use, this isn’t a problem. If you need high concurrency, run multiple Piper instances behind a load balancer.

Explore Piper in our AI Homelab Toolkit.