TL;DR: audio.cpp is what llama.cpp is for LLMs, but for audio — a pure C++/ggml inference engine that runs TTS, speech-to-text, voice conversion, and music generation with zero Python at runtime. It’s Apache 2.0, launched June 25, 2026, and already covers 44 model families as of release 0.5. Build it once, and Qwen3-TTS or PocketTTS runs from a single binary.

	audio.cpp	Coqui TTS	piper-tts
Best for	Modern TTS/VC models, one engine for everything	Legacy XTTS pipelines you already run	Fast, tiny voices on a Raspberry Pi
Language / runtime	C++ / ggml, no Python	Python / PyTorch	C++ / ONNX
License	Apache 2.0	MPL 2.0 (code); project unmaintained since 2024	MIT
The catch	Young project, docs still catching up to the model list	Abandoned upstream, heavy dependencies	Limited voice quality ceiling, no cloning

Honest take: if you want current-generation TTS (Qwen3-TTS, PocketTTS, VeVo2) on your own hardware without a conda environment, audio.cpp is the setup to learn — it’s faster than the Python reference implementations and installs like llama.cpp. Keep piper for embedded boards; forget Coqui unless you’re maintaining an old pipeline.

The local speech stack has had a llama.cpp-shaped hole in it for years. Speech-to-text got whisper.cpp back in 2022, and we compared its descendants in the faster-whisper vs Whisper.cpp vs WhisperX shootout. But text-to-speech stayed stuck in Python: every new model shipped as a PyTorch repo with its own conda environment, its own CUDA version pin, and its own half-documented inference script.

audio.cpp closes that hole. Released by ShugoAI on June 25, 2026 as v0.1.0 with 12 models, it hit release 0.5 on July 31, 2026 with 44 supported model families across TTS, ASR, voice activity detection, voice conversion, speaker diarization, source separation, and music generation. One engine, one CLI, GGUF-style quantized weights, and backends for CUDA, Metal, HIP/ROCm, Vulkan, and plain CPU.

License check: Apache 2.0, genuinely clean

The LICENSE file in the repo is Apache License 2.0, applied by ShugoAI LLC. No revenue caps, no network-use clauses, no “contact us for commercial use” asterisks. You can self-host it, ship it inside a commercial product, and modify it freely with standard attribution.

One nuance that matters more here than with LLM runners: the engine license is not the model license. audio.cpp runs 44 model families, and each family’s weights carry their own terms. Qwen3-TTS follows Qwen’s licensing (permissive for the small models), PocketTTS from Kyutai is MIT, but you should check the HuggingFace model card for anything you plan to use commercially — especially voice-cloning models, where the legal question is less about the license and more about whose voice you’re cloning. The engine being Apache 2.0 doesn’t launder the weights.

What you’re actually getting

The pitch is performance plus consolidation. ShugoAI’s benchmarks claim TTS runs 1.8x to 8x faster than the Python reference implementations on the same hardware. Third-party confirmation exists for at least one model: Kyutai’s own pocket-tts issue tracker has a report of the ggml implementation running 3.22x faster than Python on CUDA. VeVo2 in one-shot mode is reported at 5.03x faster than PyTorch on the same GPU.

The consolidation matters just as much. Before audio.cpp, running Qwen3-TTS, a voice converter, and a VAD model meant three Python environments. Now it’s one binary and a --family flag. The supported list as of release 0.5 includes:

• TTS and voice cloning: Qwen3-TTS (0.6B and 1.7B), PocketTTS, VoxCPM2, VeVo2, VibeVoice, MioTTS, OmniVoice, Chatterbox, Higgs Audio, Fish Audio, MOSS-TTS variants, Supertonic 3
• Speech-to-text: Qwen3-ASR, Nemotron, Voxtral, Fun-ASR-Nano
• Voice conversion: SeedVC, RVC, Chatterbox
• Music generation: Stable Audio 3, ACE-Step

Model sizes run 0.6B to 7B parameters. Qwen3-TTS 1.7B needs about 4.2GB VRAM in FP16, so any 8GB card from the RTX 30-series up runs it in real time — this is not an LLM-class hardware problem. If you’re speccing a machine for a full local voice pipeline, an RTX 3060 12GB covers TTS plus a Whisper-class STT model simultaneously; the sister-site audio.cpp GPU guide on runaihome.com has per-model VRAM and speed tables if hardware is the open question.

Build from source

There are no distro packages yet; you build it like llama.cpp. Prerequisites are git, cmake, and a C++ toolchain — plus the CUDA toolkit if you want the NVIDIA backend.

git clone https://github.com/0xShug0/audio.cpp
cd audio.cpp

# NVIDIA GPU
cmake -B build -DENGINE_ENABLE_CUDA=ON
cmake --build build --config Release -j

# Apple Silicon
cmake -B build -DENGINE_ENABLE_METAL=ON
cmake --build build --config Release -j

# AMD (HIP/ROCm, expanded in release 0.5)
cmake -B build -DENGINE_ENABLE_HIP=ON
cmake --build build --config Release -j

# CPU only: no flags needed
cmake -B build && cmake --build build --config Release -j

The repo also ships helper scripts that wrap these presets — scripts/build_linux.sh --backend cuda on Linux, scripts/build_windows.ps1 -Preset windows-cuda-release on Windows, and scripts/build_metal.sh on macOS. On a mainstream Linux box with CUDA already installed, the build is a few minutes; the output you care about is the audiocpp_cli binary in build/.

Note the flag prefix: it’s ENGINE_ENABLE_CUDA, not llama.cpp’s GGML_CUDA. Muscle memory from other ggml projects will produce a silently CPU-only build — which brings us to the first real gotcha.

The problem you will actually hit: it’s slow until you say --backend cuda

The CPU backend is the default. Build with CUDA enabled, run a test sentence, and generation still crawls — because the CLI ran on CPU and nothing warned you. Every GPU inference command needs the backend stated explicitly:

./build/audiocpp_cli --task tts --family qwen3_tts \
  --model models/qwen3-tts-1.7b \
  --backend cuda \
  --text "Local text to speech with no Python environment." \
  --out hello.wav

Expected behavior on an 8GB+ NVIDIA card: the model loads in a few seconds, VRAM use sits around 4.2GB for the 1.7B FP16 weights, and synthesis of a short sentence completes faster than the audio’s own duration — that’s the real-time bar. If instead you see multi-second-per-word generation and near-zero VRAM use in nvidia-smi, you’re on the CPU path: either the --backend flag is missing or the build didn’t actually pick up ENGINE_ENABLE_CUDA=ON. Re-run cmake and check its output for the CUDA detection line.

Running PocketTTS with voice presets and cloning

PocketTTS (Kyutai’s small CPU-friendly TTS) is the family to start with if your hardware is modest. It supports five languages selected at load time, plus preset voices and reference-audio cloning:

# Preset voice
./build/audiocpp_cli --task tts --family pocket_tts \
  --model models/pocket-tts \
  --backend cuda \
  --text "Hello from PocketTTS." \
  --voice-id alba --out out.wav

# Different language at load time
./build/audiocpp_cli --task tts --family pocket_tts \
  --model models/pocket-tts \
  --load-option language=spanish \
  --text "Hola desde PocketTTS." --out hola.wav

Swap --voice-id for --voice-ref your-sample.wav to clone from reference audio. Long inputs are chunked automatically (--text-chunk-size, default 256 characters) — relevant if you’re batch-narrating documents, since chunk boundaries are where prosody seams show up. Supported languages at load time: English, German, Italian, Portuguese, Spanish.

For voice conversion — restyling existing audio into another voice rather than synthesizing from text — the SeedVC family uses the same pattern with an input file plus a reference:

./build/audiocpp_cli --task vc --family seed_vc \
  --model models/seed-vc \
  --backend cuda \
  --audio input.wav --voice-ref target-voice.wav --out converted.wav

The docs split model specifics across dedicated pages (Qwen3-TTS, VeVo2, Seed-VC, ACE-Step, and Stable Audio each have their own), and as of August 2026 some details — exact reference-audio length requirements for SeedVC, per-model output sample rates — are thin or missing. That’s the young-project tax. When a flag isn’t documented, audiocpp_cli --help and the docs/ directory in the repo are more current than any blog post, including this one.

Quantization: q8_0 is free performance

Like llama.cpp, audio.cpp runs quantized weights, controlled per model family:

./build/audiocpp_cli --task tts --family qwen3_tts \
  --model models/qwen3-tts-1.7b \
  --backend cuda \
  --session-option qwen3_tts.weight_type=q8_0 \
  --text "Quantized synthesis test." --out q8.wav

The project’s own numbers for Q8 GGUF packages: up to 1.53x faster than FP16 while cutting peak VRAM roughly 37%. Unlike 4-bit LLM quantization, q8_0 on TTS models is close to inaudible in output quality — audio models are small enough that there’s little reason to push below 8-bit, and the project notes quantization effectiveness varies by model, so A/B a sample before committing a pipeline to it. At q8_0, Qwen3-TTS 1.7B drops under 3GB VRAM, which puts the whole thing in integrated-GPU and small-card territory.

If your workload is bigger — batch-narrating an audiobook library, or Supertonic 3’s claimed 10 hours of audio in 3 minutes, which ShugoAI benchmarked on an RTX 5090 — renting the GPU beats buying one for a one-off job. A few hours on RunPod covers a full library conversion for a couple of dollars, and the same binary builds identically in a cloud container.

Where audio.cpp beats the alternatives — and where it doesn’t

Against Python reference implementations: audio.cpp wins on speed (1.8–8x claimed, 3.22x independently reported for PocketTTS), deployment weight (one binary vs. a multi-GB PyTorch environment), and model coverage breadth. Python still wins for training, fine-tuning, and day-zero access to brand-new models — ggml ports land after the PyTorch release, not with it.

Against piper-tts: piper remains the right choice for embedded and low-power deployments — its ONNX voices are tiny and fast on a Pi. But piper has no voice cloning and its quality ceiling is a generation behind Qwen3-TTS or PocketTTS. If you have any GPU at all, audio.cpp gets you noticeably better speech.

Against Coqui TTS: Coqui was the 2022–2023 answer and is unmaintained since the company shut down in early 2024. Don’t start anything new on it.

There’s also a practical pairing here rather than a rivalry: whisper.cpp handles speech-in, audio.cpp handles speech-out, and both are ggml projects that build the same way. That’s a complete local voice loop in C++ — the missing piece a lot of self-hosted assistant builds have been waiting for. For higher-ceiling GPU voice cloning, MOSS-TTS is also on the supported-families list now, so the standalone Python setup we reviewed is no longer the only way to run it.

When NOT to use audio.cpp

• You need training or fine-tuning. This is inference only. Voice fine-tuning stays in PyTorch land.
• You want a supported, stable API. The project is six weeks old and moving fast — release 0.5 added nine model families in a month. Flags and formats may shift between releases; pin a commit for anything production-shaped.
• You need a polished server out of the box. The core deliverable is a CLI binary. There’s a community WebUI project (audio.cpp-webui) and an HTTP server is the obvious roadmap item, but if you want a turnkey multi-user speech API today, this isn’t that yet.
• Day-zero model access matters. New TTS models appear in Python first. If you chase releases the week they drop, you’ll still need Python environments alongside this.

FAQ

Does audio.cpp replace whisper.cpp? Not necessarily. audio.cpp does include ASR families (Qwen3-ASR, Voxtral, Nemotron, Fun-ASR-Nano), so it can do speech-to-text. But whisper.cpp is mature, battle-tested, and better documented for STT. The pragmatic 2026 stack is whisper.cpp (or one of its faster descendants) for ears and audio.cpp for voice.

What hardware do I need? Less than you think. The models are 0.6B–7B parameters; Qwen3-TTS 1.7B runs in ~4.2GB VRAM at FP16 and under 3GB at q8_0. Any 8GB RTX 30-series or newer card is comfortably real-time, Apple Silicon works via the Metal backend, and PocketTTS is usable on plain CPU.

Is the output free to use commercially? The engine is Apache 2.0, so the software side is clean. The audio you generate is governed by each model’s weight license and, for cloning, by rights to the reference voice. Check the model card on HuggingFace per family — the engine’s license doesn’t transfer to the weights.

Sources

• audio.cpp GitHub repository (0xShug0/audio.cpp) — README, supported models table, build scripts
• audio.cpp LICENSE file — Apache 2.0, ShugoAI LLC
• audio.cpp TTS documentation — CLI commands and PocketTTS flags
• Kyutai pocket-tts issue #203 — independent 3.22x CUDA speedup report
• runaihome.com audio.cpp GPU guide — per-model VRAM and hardware benchmarks

Recommended Gear

• RTX 3060 12GB — enough VRAM for Qwen3-TTS plus an STT model side by side; the budget local-voice card
• RTX 5090 — for batch narration workloads like Supertonic 3’s 10-hours-in-3-minutes benchmark