Text-to-Speech

Text-to-speech (TTS) synthesizes spoken audio from written text. Modern neural TTS produces voices natural enough to be hard to distinguish from a recording, and several capable models ship with open weights, so an operator can generate speech locally without sending a single sentence to a cloud service. It is the output half of any voice interface: where speech-to-text lets a machine listen, TTS lets it answer.

The two-stage pipeline

A typical neural TTS system works in two steps. First an acoustic model maps the input text to time-aligned acoustic features, most commonly a mel spectrogram, which encodes how the sound's frequency content should evolve over time — pitch contours, phoneme durations, pauses. Then a vocoder converts that spectrogram into an actual audio waveform, sample by sample. Tacotron 2 is a landmark example of the architecture: a sequence-to-sequence network predicts mel spectrograms from character embeddings, and a WaveNet-style neural vocoder turns those spectrograms into raw audio. Later vocoders such as WaveGlow generate high-quality speech faster than real time, which is what made neural TTS practical for everyday use rather than a research demo. Newer open models continue to compress this pipeline — some collapse it into a single end-to-end network — but the spectrogram-then-vocoder mental model remains the clearest way to understand what is happening under the hood.

Running it on your own hardware

Local TTS is one of the friendlier self-hosting workloads. Smaller open models produce intelligible, pleasant speech on a bare CPU in real time, while higher-fidelity or multi-speaker models benefit from a GPU with modest VRAM. Because synthesis is bursty — you generate a sentence, then silence — TTS coexists easily on a box that also runs local inference for a language model. The practical trade is the same as everywhere in local AI: bigger models sound more natural and handle unusual words better, smaller ones respond faster and fit humbler hardware. For a spoken status report from a node or miner, a small fast voice is plenty; for reading long documents aloud, fidelity earns its compute.

Sovereignty considerations

Running TTS locally keeps written content — which may be private notes, documentation, correspondence, or your own system's telemetry — off third-party servers, and it keeps working when the internet does not. That offline resilience matters to the same people who run their own nodes: a voice interface that dies with your WAN link is a convenience, not infrastructure. This is the approach behind D-Central's local voice work, which pairs self-hosted TTS with local speech-to-text so a complete assistant — ears, brain, and voice — runs on hardware you control; see the DCENT hub for where that fits in the wider sovereign stack. One caution deserves its own sentence: voice-cloning capabilities in some modern models raise legitimate consent and misuse concerns, so a sovereign operator should treat reference voice recordings as sensitive data — yours and everyone else's.

Choosing a local voice

Selecting a TTS model is a more subjective exercise than most local-AI choices, because the failure mode is not wrong answers but listener fatigue. Test candidates on your actual content — technical vocabulary, model numbers, mixed English and French if your household runs both — and listen for how the voice handles abbreviations, numbers, and units, which is where synthetic speech most often stumbles. Pay attention to pronunciation-control features: the ability to spell out how a term should be spoken saves endless irritation when your assistant reads "S19j Pro" aloud several times a day. And keep the pipeline modular; the field moves quickly, and a well-separated speech layer lets you swap in a better voice next year without touching anything upstream.

D-Central documents text-to-speech as the output half of a voice interface; the input half, turning speech into text, is speech-to-text. Together they let a self-hosted assistant both listen and speak entirely on local hardware.