Blog / AI / Speech

The Evolution of Text-to-Speech: A Practical Guide for Engineers

At NxtWave, we have various use cases that involve a TTS step. Recently, we started exploring open-source models as well for cost optimization and low latency, and while doing so, we've gathered a good understanding of how the TTS landscape has evolved over the years. This post walks through that evolution and helps you, as an engineer, figure out the right model for your specific task.

Key Terms

Before we get started, there are a few terms that will keep coming up throughout this post:

Terminology
Phonemes
The smallest units of sound in a language. Most TTS systems convert text into phonemes first before generating audio.
Mel Spectrograms
A visual representation of audio frequencies over time, weighted to match how humans perceive pitch. Many TTS models generate a mel spectrogram as an intermediate step, which then gets converted to actual audio.
Vocoders
The component that takes a mel spectrogram and converts it into a raw audio waveform. Examples include WaveGlow, HiFi-GAN, and Vocos.
G2P (Grapheme-to-Phoneme)
The process of converting written text (graphemes) into phoneme sequences. Some systems use rule-based G2P (like eSpeak), others use neural models, and some modern systems skip G2P entirely.
Neural Audio Codecs
Models like EnCodec, SNAC, and Mimi that compress audio into sequences of discrete tokens using RVQ. This lets language models treat audio the same way they treat text.
RVQ (Residual Vector Quantization)
A multi-layer quantization technique where each level captures finer detail than the last. The first level (C0/C1) captures coarse structure; later levels add acoustic richness.
MOS (Mean Opinion Score)
The standard subjective quality metric for TTS. Human listeners rate audio on a 1–5 scale. Professional human speech typically scores around 4.5–4.6.
RTF (Real-Time Factor)
The ratio of generation time to audio duration. An RTF of 0.5 means the system generates audio twice as fast as real-time. Lower is better.

What's a Mel Spectrogram, exactly?

Since mel spectrograms show up in almost every modern TTS architecture, it's worth understanding what they actually are. Think of it as a heat map of sound: the x-axis is time, the y-axis is frequency (on a mel scale that mirrors how our ears work), and the color intensity represents energy. Low frequencies get more resolution because that's where human speech carries most of its information.

Mel spectrogram explanation showing raw audio waveform being transformed into a mel spectrogram via Short-Time Fourier Transform and Mel Filter Bank

From Waveform to Mel Spectrogram

Raw audio is a 1D signal (amplitude over time). To get a mel spectrogram, you slide a short window across the audio and compute the frequency content at each step using the Short-Time Fourier Transform.

The resulting frequencies are then mapped onto the mel scale, which compresses higher frequencies and expands lower ones. This matches human hearing: we're much better at distinguishing between 200Hz and 400Hz than between 8000Hz and 8200Hz.

The final output is an 80-channel "image" of the audio that a neural network can learn to generate or process. Most modern TTS models either produce mel spectrograms as output (then use a vocoder) or learn from them during training.

The Pre-Deep Learning Era (1980s-2015)

Before neural networks, TTS went through three distinct generations, each trading off quality, data requirements, and flexibility in different ways.

Formant Synthesis (1980s, eSpeak / DECTalk)

This is where it all started. No recordings, no neural networks, no data at all. Formant synthesis works by modelling the human vocal tract as a set of resonant filters and generating waveforms from scratch using hand-crafted rules. You map phonemes to formant frequencies (F1, F2, F3), set the bandwidths, and combine sine waves. The entire engine fits in kilobytes and runs on pretty much anything, including the embedded hardware of the 1980s.

DECTalk was the voice Stephen Hawking used for decades, and if you've ever heard that iconic robotic voice, that's formant synthesis in action. eSpeak is still alive today as eSpeak-ng, and it shows up in a lot of modern pipelines. Piper, for instance, uses it as a phonemizer. The output is unmistakably robotic, but for pure efficiency and zero dependency on data, nothing else comes close.

Key: No data needed. Runs on anything. KBs in size. Robotic but intelligible output.
▶ Formant Sample (eSpeak-ng)
graph TD A["Text Input"] --> B["Text Normalizer"] B --> C["Letter-to-Phoneme Rules"] C --> D["Formant Parameters"] D --> E["Source-Filter Synthesis"] E --> F["Audio Output"]

Concatenative Synthesis (1990s-2000s)

The next idea was pretty intuitive: why generate speech from scratch when you can just stitch together small pieces of real recorded speech? You build a massive database of a single speaker (typically 10 to 40 hours of studio recordings), segment it into tiny units like diphones or triphones, and at synthesis time the system searches for the best sequence of units that match the target phonetics and join smoothly at the boundaries.

Apple's original Siri (pre-2017), AT&T Natural Voices, and Nuance Vocalizer all used this approach. The results sounded far more natural than formant synthesis because you're working with actual human speech. But there were two big downsides: you needed gigabytes of recordings for each voice (and adding a new voice meant months in a recording studio), and there were always audible artifacts at the join points where chunks got stitched together. You could hear it as slight glitches or unnatural transitions.

Key: Real speech chunks. Natural but jointy. GBs of data per voice. Adding a new voice means months of recording.
graph TD A["Text"] --> B["Prosody Prediction"] B --> C["Unit Selection Engine"] C --> D["Concatenation + Smoothing"] D --> E["Audio Output"]

HMM-Based Synthesis (2000s-2015, HTS)

Statistical parametric synthesis took a completely different angle. Instead of storing recorded speech, you train Hidden Markov Models to predict acoustic parameters (mel-cepstral coefficients for the spectrum, fundamental frequency for pitch, and duration for each phoneme state) from linguistic features. A vocoder (typically the MLSA filter) then reconstructs the waveform from these predicted parameters. The most widely used framework was HTS, and it powered a lot of commercial systems through the 2000s and early 2010s.

The big advantage was size and flexibility. Models were compact (around 2MB per voice compared to gigabytes for concatenative systems), and you could adapt to a new speaker from just minutes of data using techniques like CMLLR. The downside was quality. The output had a characteristic "buzzy" or "muffled" quality that came from vocoder artifacts and the statistical over-smoothing that HMMs tend to produce. It was flexible, but it never quite sounded natural.

Key: Compact models (~MBs). Speaker adaptation from minutes of data. Flexible but muffled output.
graph TD A["Text"] --> B["Phoneme + Linguistic Features"] B --> C["HMM Parameter Generation"] C --> D["Trajectory Smoothing"] D --> E["MLSA Vocoder"] E --> F["Audio Output"]

Deep Learning Enters the Picture (2016-2018)

2016 marked a fundamental shift: neural networks started generating speech that sounded dramatically more natural than anything rule-based or statistical systems could produce. The trade-off was speed and compute, but quality was no longer the bottleneck.

WaveNet (2016, Google DeepMind)

WaveNet was the moment everything changed. Google DeepMind showed that a neural network could generate raw audio waveforms that sounded dramatically better than any traditional signal processing approach. The architecture is an autoregressive model built on dilated causal convolutions with exponentially growing receptive fields (dilation factors of 1, 2, 4, all the way up to 512). Each layer "sees" further back in time, letting the model capture both fine-grained audio detail and longer-term structure.

The quality was a genuine leap forward, but there was a catch: generating 1 second of 16kHz audio required 16,000 sequential forward passes. That made it roughly 1000x slower than real-time, completely impractical for production. But it proved the concept so convincingly that it kicked off a whole family of faster alternatives. Parallel WaveNet, WaveRNN, WaveGlow, and eventually HiFi-GAN (which hit 167x real-time on GPU) all came out of the need to make WaveNet's quality practical.

Key: Proved neural audio generation was viable. 1000x slower than real-time. Spawned a whole family of faster vocoders.
graph TD A["Text"] --> B["TTS Frontend"] B --> C["Dilated Causal Conv Stack"] C --> D["Softmax Prediction"] D --> E["Audio Sample"] E -->|"Autoregressive Feedback"| C

Tacotron 2 (2018, Google)

Tacotron 2 was where end-to-end TTS truly arrived. The idea was simple but ambitious: take raw text characters, and map them directly to mel spectrograms using a sequence-to-sequence architecture. Character embeddings pass through convolutional layers and a bidirectional LSTM encoder, then an autoregressive decoder with location-sensitive attention predicts mel frames one at a time. A post-net refines the output, and a vocoder (initially WaveNet, later HiFi-GAN) turns the mel spectrogram into audio.

The results were kind of shocking at the time. Tacotron 2 achieved a Mean Opinion Score of 4.53, which was statistically indistinguishable from professionally recorded human speech (MOS 4.58). It proved that with enough data, you didn't need any of the hand-engineered linguistic features that traditional systems relied on. Characters in, natural-sounding speech out. That simplicity is what made it such a big deal.

Key: First end-to-end TTS to match human quality. Characters in, mel spectrogram out. MOS 4.53 vs human 4.58.
▶ Tacotron 2 Sample
graph TD A["Text Characters"] --> B["Embedding + Conv + BiLSTM"] B --> C["Location-Sensitive Attention"] C --> D["Autoregressive Decoder"] D --> E["Post-Net Refinement"] E --> F["Mel Spectrogram"] F --> G["WaveGlow / HiFi-GAN"] G --> H["Audio Output"]

The Transformer and Flow Era (2019-2021)

Tacotron 2's autoregressive approach sounded great but was slow and sometimes unreliable (the attention mechanism could skip or repeat words). This era solved both problems: Transformers enabled parallel generation, flow-based models learned alignments without external tools, and VITS unified the entire pipeline into a single end-to-end model.

FastSpeech 2 (2020, Microsoft)

Tacotron 2 sounded great but had some real problems in practice. Because it generated mel frames one at a time (autoregressively), it was slow, and the attention mechanism would sometimes fail, causing it to skip or repeat words. FastSpeech 2 from Microsoft fixed both issues. Instead of autoregressive generation, it uses a Feed-Forward Transformer encoder on phonemes, then a variance adaptor that explicitly predicts three things: duration, pitch (F0), and energy for each phoneme. These predictions are used to expand phoneme-level representations to frame-level, and a Transformer decoder produces the full mel spectrogram in a single parallel pass.

The result was a 270x speedup in mel spectrogram generation compared to Tacotron. And because duration, pitch, and energy are predicted explicitly, you get fine-grained control over prosody. Want a word emphasized? Adjust the energy predictor. Want a slower delivery? Scale the duration. That kind of control was a big deal for production systems.

Key: Non-autoregressive. 270x faster than Tacotron. Full prosody control via duration/pitch/energy predictors.
graph TD A["Phonemes"] --> B["FFT Encoder"] B --> C["Duration Predictor"] B --> D["Pitch Predictor"] B --> E["Energy Predictor"] C --> F["Length Regulator"] D --> F E --> F F --> G["FFT Decoder"] G --> H["Mel Spectrogram"] H --> I["HiFi-GAN"] I --> J["Audio"]

Around the same time, flow-based models offered an alternative approach. Instead of predicting mel frames in parallel like FastSpeech, Glow-TTS used normalizing flows to model the distribution of speech directly.

Glow-TTS (2020)

While FastSpeech was tackling speed, Glow-TTS came at the problem from a different angle using normalizing flows. The core idea is elegant: use invertible 1x1 convolutions and affine coupling layers to learn a transformation from a simple Gaussian distribution to the complex distribution of mel spectrograms. During training, you run the flow forward (mel to Gaussian) to compute exact likelihoods. At inference, you run it backward (Gaussian to mel) to generate speech.

The really clever part was Monotonic Alignment Search (MAS), a dynamic programming algorithm that learns text-to-audio alignment during training without needing any external aligner. Previous systems relied on tools like Montreal Forced Aligner to pre-compute alignments, which added complexity and error. Glow-TTS eliminated that step entirely. It was 15.7x faster than Tacotron 2 and needed only 1.5 seconds to synthesize one minute of speech.

Key: Non-autoregressive. 15.7x faster than Tacotron 2. No external aligner needed. MAS learns alignment internally.
graph TD A["Text"] --> B["Transformer Encoder"] B --> C["Duration Predictor"] B --> D["Monotonic Alignment Search"] C --> E["Upsample Prior"] E --> F["Normalizing Flow"] F --> G["Mel Spectrogram"] G --> H["HiFi-GAN"] H --> I["Audio"]

The biggest breakthrough of this era came with VITS (2021), which asked: why have a two-stage pipeline at all?

VITS (2021)

VITS was a real game changer. It was the first model to go fully end-to-end: text in, raw waveform out, all in a single model. No separate vocoder, no two-stage pipeline. Under the hood, it combines four ideas into one architecture: a variational autoencoder (VAE) for learning latent speech representations, normalizing flows for flexible posterior modeling, adversarial training with multi-period and multi-scale discriminators for high-quality waveform generation, and Monotonic Alignment Search for learning alignment without external tools.

It also introduced a stochastic duration predictor, which meant the same text could produce slightly different rhythms each time, making the output sound more natural and less "machine-like". On the LJ Speech benchmark, VITS matched ground truth recordings in subjective quality tests. That's a big statement. And because it was a clean, well-designed architecture, it became the foundation for many practical systems that came after: Piper, MeloTTS, and quite a few others all build directly on VITS.

Key: Single-stage, end-to-end. Text to waveform directly. Quality matches ground truth. Foundation for many later systems.
▶ VITS Sample
graph TD A["Text"] --> B["Transformer Encoder"] B --> C["Stochastic Duration Predictor"] B --> D["Sample z from Prior"] C --> E["Upsample"] D --> E E --> F["Normalizing Flow Inverse"] F --> G["HiFi-GAN Decoder"] G --> H["Audio Output"]

Practical and Lightweight Models (2022-2023)

With VITS proving the architecture, a wave of practical, deployable models emerged that focused on specific real-world needs.

Piper TTS (2023)

Piper is what happens when you take VITS and optimize it for the real world. The idea is straightforward: train VITS voices, then export them to ONNX format so they can run through ONNX Runtime on CPUs. The result is a TTS engine that can run on a Raspberry Pi in real-time, completely offline, with no cloud dependency and no GPU required. It uses eSpeak-ng as its phonemizer (there's that formant synthesis engine showing up again), so the entire pipeline stays lightweight.

Piper supports over 30 languages and has become the default recommendation if your use case involves edge deployment, local voice assistants, home automation, or anything where you need fast, private, CPU-only inference. The quality is solid (it's VITS under the hood, after all), and the simplicity of deployment is hard to beat. Drop in an ONNX file and a JSON config, and you have a working TTS system.

Key: VITS exported to ONNX. Raspberry Pi, CPU-only, offline. 30+ languages. No GPU needed.
graph TD A["Text"] --> B["eSpeak-ng Phonemizer"] B --> C["VITS via ONNX Runtime"] C --> D["Audio Output"]

MeloTTS (2023, MyShell + MIT)

MeloTTS from MyShell and MIT focused on a specific gap: multilingual TTS that can actually run in real-time on a CPU. It supports English (with accent variants for American, British, Indian, and Australian), Spanish, French, Chinese, Japanese, and Korean. What makes it stand out from plain VITS-based systems is its use of BERT for prosody extraction. Instead of relying only on phoneme sequences, MeloTTS feeds the text through a BERT model to capture semantic and prosodic context, which gives it noticeably better intonation and natural emphasis.

Under the hood, it's built on VITS2 with a distilled architecture and uses NSF-HiFiGAN (a lightweight 1.5M parameter decoder) for waveform generation. A single 180MB checkpoint covers all languages, and it achieves a real-time factor of 0.4 to 0.55 on CPU. MIT-licensed, so there are no restrictions on commercial use. If you need decent multilingual TTS without heavy compute, MeloTTS is a strong practical choice.

Key: CPU real-time. 7 languages. BERT prosody. MIT-licensed. Single 180MB model.
graph TD A["Text"] --> B["Phonemizer + Tones"] A --> C["BERT Prosody"] B --> D["VITS2 Encoder"] C --> D D --> E["Flow + Duration"] E --> F["NSF-HiFiGAN"] F --> G["Audio"]

GPT-SoVITS (2023)

GPT-SoVITS came at the problem from the voice cloning angle, and it hit a sweet spot between effort and results. The architecture is a two-stage pipeline: a GPT-style language model handles the "what to say" part (predicting semantic tokens from text, conditioned on reference audio), and then SoVITS (a modified VITS) handles the "how it sounds" part (converting semantic tokens into audio while preserving the speaker's timbre). Both stages use BERT features for better prosody.

The practical appeal is in the data requirements. You can do zero-shot cloning with just 5 seconds of reference audio, or fine-tune with about 1 minute of data for much better speaker similarity. It supports cross-lingual inference across Chinese, English, Japanese, Korean, and Cantonese. With over 55,000 stars on GitHub, the community adoption speaks for itself. If you're looking for quick, accessible voice cloning without heavy infrastructure, GPT-SoVITS is worth trying.

Key: Two-stage: GPT for semantics, SoVITS for acoustics. 5s zero-shot, 1min fine-tune. 5 languages.
graph TD R["Reference Audio"] --> S["Semantic Tokens"] A["Text"] --> B["Phoneme + BERT"] S --> C["GPT Decoder"] B --> C C --> D["SoVITS Synthesis"] D --> E["Cloned Voice"]

The Zero-Shot Cloning Era: LLM Meets TTS (2023)

2023 was the year TTS started borrowing heavily from the large language model playbook. The idea was simple but powerful: treat speech as a sequence of discrete tokens (using neural audio codecs) and model them with a language model. This unlocked zero-shot voice cloning, where you could clone any voice with just a few seconds of reference audio without any fine-tuning.

VALL-E (2023, Microsoft)

VALL-E was one of the first models to ask: what if we treat TTS the same way we treat text generation in large language models? Instead of predicting mel spectrograms, you use a neural audio codec (Meta's EnCodec) to tokenize audio into 8 levels of discrete codes using Residual Vector Quantization. Then you train a language model to predict these codes. An autoregressive Transformer handles the coarse first-level codes (C1), which capture the broad structure of the speech. Then a non-autoregressive Transformer fills in the detail codes (C2 through C8) in parallel, adding acoustic richness.

Trained on 60,000 hours of English speech (LibriLight), VALL-E could clone a voice from just 3 seconds of audio. And it didn't just copy the voice. It preserved the speaker's emotion, their pacing, even the acoustic environment of the reference recording. VALL-E 2 later achieved human parity on benchmarks like LibriSpeech and VCTK. The model itself was slow at inference (around 2 seconds per utterance), but it proved that the "language model over audio tokens" paradigm worked, and that idea went on to influence almost every major TTS system that followed.

Key: TTS as language modeling over audio codes. AR + NAR Transformers. 60K hours training. 3-second voice cloning.
graph TD A["Text"] --> B["Phonemes"] R["Reference 3s"] --> C["EnCodec RVQ"] B --> D["AR Transformer"] C --> D D --> E["NAR Transformer"] C --> E E --> F["EnCodec Decoder"] F --> G["Audio Output"]

XTTS v2 (2023, Coqui)

While VALL-E was a research model, XTTS from Coqui brought zero-shot voice cloning to the open-source community in a usable form. Built on top of Tortoise TTS, it uses a Perceiver encoder to compress reference audio (any length) into exactly 32 fixed-length latent vectors that capture speaker identity. These 32 vectors get prepended to BPE text tokens and fed into a GPT-2 decoder that autoregressively generates discrete audio tokens. A HiFi-GAN vocoder then converts those tokens to the final waveform.

The practical result was impressive: clone any voice from a 6-second sample across 16 languages, with emotion and style transfer, at under 150ms streaming latency on consumer GPUs. Because the Perceiver compresses to a fixed 32 vectors regardless of reference length, you could also provide multiple or longer reference clips without blowing up the context window. For a good stretch of 2023, XTTS was the go-to open-source option if you needed multilingual zero-shot cloning that actually worked.

Key: Perceiver compresses reference to 32 vectors. GPT-2 decoder. 16 languages. Under 150ms streaming latency.
▶ XTTS v2 Reference Sample
graph TD A["Text"] --> B["BPE Tokens"] R["Reference 6s"] --> C["Perceiver Encoder"] B --> D["GPT-2 Decoder"] C --> D D --> E["Audio Tokens"] E --> F["HiFi-GAN"] F --> G["Audio"]

VoiceBox (2023, Meta FAIR)

VoiceBox from Meta's FAIR team went in a completely different direction from the autoregressive language modeling approach. Instead of predicting tokens one at a time, it uses non-autoregressive flow matching and frames TTS as a speech infilling problem. Give it some surrounding audio context and a phoneme transcript, and it fills in the masked region. A Transformer backbone learns a vector field that transports Gaussian noise to the target speech distribution, solved iteratively using an ODE solver (typically around 16 steps).

The results were compelling. Trained on over 50,000 hours of unfiltered speech data, VoiceBox was 20x faster than VALL-E at inference while actually having lower word error rates (1.9% vs VALL-E's 5.9%). But the real power of the infilling approach is its versatility. The same model, with no changes, can do standard TTS, noise removal, content editing (change a word in existing audio), and style conversion. That multi-task capability from a single architecture was a strong argument for the flow matching paradigm.

Key: Non-autoregressive flow matching. 20x faster than VALL-E. Multi-task: TTS + editing + denoising.
graph TD A["Text Transcript"] --> E["Duration Model"] C["Audio Context"] --> D["Masked Audio"] D --> E E --> F["Flow Matching Transformer"] F --> G["Generated Mel"] G --> H["HiFi-GAN"] H --> I["Audio"]

Diffusion and Flow Matching Models (2023-2024)

While the LLM-based approach was gaining traction, another line of research was pushing quality to human level using diffusion and flow matching techniques.

StyleTTS 2 (2023)

StyleTTS 2 approached TTS quality from a unique angle: what if you treated speech style (pitch patterns, rhythm, speaking rate, emphasis) as a latent random variable and modeled it with a diffusion process? At inference time, a diffusion module takes just the text input and generates an appropriate style vector, no reference audio needed. The decoder then produces waveforms conditioned on both the text encoding and this generated style vector. The model learns to pick a natural-sounding style for whatever text you give it.

The secret sauce here is the discriminator. Instead of using traditional reconstruction losses or simple waveform discriminators, StyleTTS 2 uses a pre-trained WavLM speech language model as the adversarial discriminator. WavLM already understands what natural speech sounds like at a deep representational level, so training against it pushes the generator far beyond what traditional loss functions can achieve. The result: StyleTTS 2 was the first TTS system to match human-level performance on both single-speaker (LJ Speech) and multi-speaker (VCTK) benchmarks. If raw audio quality is your top priority and you're okay with English only, StyleTTS 2 is still one of the best things out there.

Key: First to match human quality on LJSpeech. Style diffusion from text, no reference audio needed. WavLM discriminator.
graph TD A["Text"] --> B["Text Encoder"] B --> C["Style Diffusion"] B --> D["Duration Model"] C --> D D --> E["Decoder"] E --> F["Audio Output"] E -.->|"Adversarial"| G["WavLM Discriminator"]

F5-TTS (2024)

F5-TTS pushed flow matching further, and what makes it really interesting is how much it simplifies the pipeline. Most TTS systems need a duration model, a text encoder, phoneme conversion, and some kind of alignment mechanism. F5-TTS throws all of that out. You take the raw text characters, pad them with filler tokens to roughly match the target speech length, run them through a ConvNeXt module for refinement, concatenate them with reference audio mel features, and feed everything into a Diffusion Transformer (DiT) that denoises the target region using conditional flow matching. That's it. No G2P, no duration predictor, no phoneme alignment.

It also introduces "Sway Sampling," which optimizes the flow matching inference steps for better efficiency without any retraining. Trained on 100,000 hours of multilingual data, F5-TTS achieves a real-time factor of 0.15, significantly faster than other diffusion-based models, and produces strong zero-shot voice cloning results. The simplicity of the pipeline makes it appealing for production, and the Vocos vocoder at the end keeps the final waveform quality high.

Key: No duration model, no phoneme alignment, no text encoder. Simplest modern pipeline. RTF 0.15. Sway Sampling.
▶ F5-TTS Zero-Shot Sample
graph TD A["Text Chars"] --> B["Pad + ConvNeXt Refiner"] R["Reference Audio"] --> C["Mel Extraction"] B --> D["Concatenate"] C --> D D --> E["DiT + Flow Matching"] E --> F["Vocos Vocoder"] F --> G["Audio"]

The Current Frontier (2025-Present)

The latest wave of TTS models is converging on an architecture pattern: take a pre-trained LLM backbone, adapt it for speech token prediction, and train on massive amounts of audio data. The results are getting remarkably close to how humans actually speak, with natural pauses, emotion, and conversational flow.

Fish Speech / OpenAudio (2024-25)

Fish Speech (recently rebranded as OpenAudio) takes the LLM-based approach and scales it up. The architecture is called Dual Autoregressive: a "slow" Transformer handles high-level linguistic structure (what to say, prosody intent, phrasing), while a "fast" Transformer handles the fine-grained acoustic details (how it sounds at the sample level). One interesting design choice is that it skips grapheme-to-phoneme conversion entirely. The LLM processes text directly, which simplifies the pipeline and removes a common source of errors in multilingual contexts.

The audio tokenization uses Firefly-GAN with Grouped Finite Scalar Vector Quantization (GFSQ), which achieves nearly 100% codebook utilization, much better than typical VQ approaches. Trained on 720,000 hours of multilingual audio, the flagship OpenAudio-S1 model (4B parameters) currently ranks #1 on TTS-Arena2 benchmarks with first-packet latency around 150ms. There's also a lighter 0.5B variant (S1-mini) for deployments where you can't justify a 4B model. If you want the current best quality in an open-source package, OpenAudio is where to look.

Key: No G2P. Dual AR: slow (semantics) + fast (acoustics). 720K hours. #1 on TTS-Arena2. ~150ms latency.
graph TD A["Text"] --> C["Slow Transformer"] R["Reference Audio"] --> B["Firefly-GAN Encoder"] B --> C C --> D["Fast Transformer"] D --> E["Firefly-GAN Decoder"] E --> F["Audio"]

Orpheus TTS (2025, Canopy Labs)

Orpheus is a fascinating example of how the line between text LLMs and speech models is blurring. Canopy Labs took a standard Llama-3.2-3B model, the same architecture that powers text chatbots, and fine-tuned it for speech token prediction. Instead of generating text tokens, it generates SNAC audio tokens at 24kHz. The training data was over 100,000 hours of English speech, and the SNAC tokenizer handles the audio codec side. Because the backbone is a standard LLM, it inherits good language understanding and can handle complex sentences, proper nouns, and nuanced phrasing well.

What sets Orpheus apart is emotion control through inline tags. You can insert markers like <laugh>, <sigh>, or <chuckle> directly in your text, and the model generates speech with those emotional expressions baked in. Streaming latency is as low as 100ms using sliding-window SNAC decoding, and the whole thing is Apache 2.0 licensed. Currently English only, but the architecture is clean enough that multilingual fine-tuning seems very feasible.

Key: Llama 3.2 3B repurposed for TTS. SNAC tokenizer. Emotion via inline tags. ~100ms streaming. Apache 2.0.
graph TD A["Text + Emotion Tags"] --> B["Llama Tokenizer"] B --> C["Modified Llama-3.2-3B"] C --> D["SNAC Tokens"] D --> E["SNAC Decoder"] E --> F["Streaming Audio"]

CSM 1B (2025, Sesame)

Most TTS models treat each utterance in isolation. You give them a sentence, they produce audio, done. CSM from Sesame was built with a fundamentally different goal: conversational speech. The 1B parameter model uses a Llama-style Transformer backbone that doesn't just see the current text input, it attends over the full conversation history. Previous turns are encoded as text plus audio pairs (tokenized via the Mimi codec from Kyutai), so the model has complete context of what's been said and how it was said.

The architecture has two stages: a backbone decoder that predicts coarse first-level RVQ tokens (C0) while attending to the full dialogue history, and a smaller depth decoder that fills in the remaining codebook levels (C1 through Cn) to add acoustic detail. What makes this practically interesting is the contextual awareness. CSM picks up on emotional states from previous turns and responds with appropriate tones. If someone in the conversation was excited, CSM naturally raises energy in its response. If you're building voice assistants or conversational AI where coherent multi-turn dialogue matters, CSM is the model built specifically for that.

Key: Designed for conversation. Full attention over dialogue history. Backbone + depth decoder. Mimi codec. Context-aware emotion.
graph TD H["Conversation History"] --> A["Encode via Mimi Codec"] T["Current Text"] --> B["Backbone Decoder 1B"] A --> B B --> C["C0 Tokens"] C --> D["Depth Decoder"] D --> E["Mimi Codec Decoder"] E --> F["Audio"]

Qwen3-TTS (2026, Alibaba)

Qwen3-TTS from Alibaba's Qwen team is one of the most recent entries, released in January 2026. Available in 0.6B and 1.7B parameter variants, it was trained on a staggering 5 million+ hours of speech data across 10 languages. The architecture uses a dual-track design where Track 1 handles text and semantic understanding while Track 2 generates acoustic tokens, and the two tracks are decoupled so the acoustic generation doesn't have to wait for the full text processing to complete. That decoupling is what gives it low latency.

Two features really stand out. First, it supports natural language voice design: instead of providing reference audio, you can just describe the voice you want in plain text ("warm female voice, slow pace, British accent") and the model generates speech matching that description. Second, there are two tokenizer options: a 25Hz single-codebook path through a block-wise DiT for quality, and a 12Hz multi-codebook path through a causal ConvNet for speed (97ms first-packet latency). Apache 2.0 licensed, and already outperforming commercial offerings like ElevenLabs and GPT-4o Audio on several benchmarks. The scale of training data is hard to ignore.

Key: Dual-track LM. 5M+ hours. 10 languages. Voice design via text description. 97ms latency. Beats ElevenLabs on benchmarks.
graph TD A["Text"] --> B["Tokenization"] V["Voice Control"] --> C["Conditioning"] B --> D["Track 1: Text Processing"] C --> D D --> E["Track 2: Acoustic Tokens"] E --> F{"Tokenizer?"} F -->|"25Hz Quality"| G["Block-wise DiT"] F -->|"12Hz Speed"| H["Causal ConvNet"] G --> I["Audio"] H --> I

Full Comparison Table

Here's every model we covered, compared across the dimensions that matter most when choosing one for production:

Model Quality Latency Size Languages Voice Cloning License Edge Support
Pre-Deep Learning
eSpeak / DECTalk 1 / 5 < 1ms < 1 MB 100+ No GPL-3.0 Any device
Unit Selection 2.5 / 5 ~50ms GBs / voice Per voice No Proprietary Needs > 1 GB RAM
HMM (HTS) 2 / 5 ~30ms ~2 MB / voice Per voice No Modified BSD Any device
Neural Era (2016-2021)
WaveNet 2.5 / 5 ~1000x RT Per model No Not released GPU only
Tacotron 2 3 / 5 ~500ms ~28M params Per model No BSD-3 GPU recommended
FastSpeech 2 2.5 / 5 ~50ms ~25M params Per model No MIT GPU recommended
Glow-TTS 2.5 / 5 ~65ms ~29M params Per model No MIT GPU recommended
VITS 3.5 / 5 ~100ms ~37M params Per model No MIT GPU recommended
Practical & Lightweight (2022-2023)
Piper TTS 3 / 5 Real-time CPU ~25 MB ONNX 30+ No MIT RPi 4+
MeloTTS 3.5 / 5 Real-time CPU 180 MB 7 No MIT Any modern CPU
GPT-SoVITS 4 / 5 ~300ms ~2 GB 5 Yes (5s zero-shot) MIT GPU required
Zero-Shot Cloning (2023)
VALL-E 4 / 5 ~2s 1 (EN) Yes (3s zero-shot) Research only GPU required
XTTS v2 4 / 5 ~150ms ~1.6 GB 16 Yes (6s zero-shot) CPML GPU ≥ 4 GB
VoiceBox 4.5 / 5 ~200ms Multi Yes Not released GPU required
Diffusion & Flow Matching (2023-2024)
StyleTTS 2 5 / 5 ~400ms ~200 MB 1 (EN) Adaptation MIT GPU recommended
F5-TTS 4.5 / 5 RTF 0.15 ~330M params Multi Yes CC-BY-NC-4.0 GPU recommended
Current Frontier (2025+)
OpenAudio S1 5 / 5 ~150ms 0.5B / 4B Multi Yes Apache 2.0 GPU ≥ 8 GB
Orpheus TTS 4.5 / 5 ~100ms 3B 1 (EN) Yes Apache 2.0 GPU ≥ 6 GB
CSM 1B 4.5 / 5 Streaming 1B 1 (EN) Context-based Apache 2.0 GPU ≥ 4 GB
Qwen3-TTS 5 / 5 97ms 0.6B / 1.7B 10 Yes (3s zero-shot) Apache 2.0 GPU ≥ 4 GB

Quality ratings are approximate MOS-normalized scores based on published benchmarks and the authors' evaluation. "Size" refers to model weights; additional vocoder size is not included for two-stage systems.

The TTS landscape is moving incredibly fast. What was state-of-the-art six months ago is already being surpassed. The best approach is to identify your key constraints (latency, quality, languages, compute budget, licensing) and evaluate the 2-3 models that best fit those constraints. Hopefully this post gives you enough context to make that decision without having to read through dozens of papers.