audio.cpp: Run TTS and Speech-to-Text Locally, With No Python and No GPU

Short answer: yes, you can run real TTS and real speech-to-text from one C++ binary with no Python and no GPU — but audio.cpp does not run Whisper. It is a ggml-based runtime covering 49 model families as of Release 0.6 (13 August 2026), with GGUF quants from 40.6MB up. The repo's one published CPU measurement has Supertonic 3 producing 379 seconds of audio in 61 seconds of wall time — about 6.2x faster than real time, on a CPU. Everything else in the speed table is CUDA.

audio.cpp is roughly two months old — the repository was created on 23 June 2026 — and stood at about 1,800 stars and 216 forks when we checked on 18 August 2026. Those numbers move daily; treat them as a snapshot, not a current reading. What matters more is the release cadence: eight releases between 7 July and 13 August 2026, the most recent being 0.6, with main being pushed to on the day we checked. That pace is the reason to be interested and the reason to be careful, in equal measure.

This page covers what actually runs on what hardware, the install path per platform, and three claims on the README that need qualifying.

---

What audio.cpp Is

It is whisper.cpp's idea applied to the whole audio stack, not just transcription. One C++ runtime on top of ggml, one CLI, one server, and a model registry that spans jobs the Python ecosystem usually needs four separate repos for:

• TTS and voice cloning — Qwen3-TTS, VibeVoice, Fish Audio S2 Pro, Higgs Audio v3, IndexTTS-2 / 2.5, Chatterbox, VoxCPM2, PocketTTS, Supertonic 3, MOSS-TTS, OmniVoice and more
• ASR — Qwen3-ASR, Parakeet-TDT 0.6B v3, Nemotron 3.5 ASR Streaming, SenseVoice-Small, Fun-ASR-Nano, Voxtral Realtime, Kroko, Citrinet, Hviske
• Voice conversion — SeedVC, RVC, MioCodec
• Diarization, VAD, forced alignment — Sortformer 4-speaker, Silero VAD, MarbleNet VAD, Qwen3-ForcedAligner
• Source separation — HTDemucs, BS-RoFormer, Mel-Band RoFormer
• Music and SFX — ACE-Step 1.5, Stable Audio 3, HeartMuLa, MuScriptor (audio to MIDI)

Backends are CUDA, HIP/ROCm, Vulkan, Metal and plain CPU. The project is Apache 2.0, copyright ShugoAI LLC.

The Whisper correction, up front. The title query for this page is usually "whisper.cpp but for TTS", and the honest answer is that audio.cpp is that architecturally and is not that by model. There is no whisper family in the supported table or in the 47 model specs in the repo. The README states it plainly: GGUF is a container, not a universal architecture adapter, and existing llama.cpp or whisper.cpp GGUF files are not automatically compatible unless their tensor names and metadata are mapped to an audio.cpp family. If Whisper weights specifically are the requirement, stay on whisper.cpp or faster-whisper. If a good transcript is the requirement, Parakeet-TDT and Qwen3-ASR are both here — see our Parakeet vs Whisper comparison for how that trade actually lands.

---

What Fits, By RAM Tier

These are real file sizes read from the audio-cpp/audio.cpp-gguf repository on 18 August 2026, not estimates. Audio models are small — the whole reason this stack works on hardware that cannot host a language model. Sizes below are the q8_0 quant where one exists.

Two things to note. First, the sub-500MB tier is not a toy: PocketTTS at 127.9MB and Supertonic 3 at 454.1MB are the two fastest models in the repo's own benchmark table. Second, the 24GB row lists folder totals because those families ship several precisions; pick one file, not the folder.

If you want the wider field rather than just what audio.cpp carries, our best local TTS models roundup covers the same voices in their native Python form.

---

Install, Per Platform

On macOS it is one Homebrew command; on Windows it is a zip; on Linux you build.

macOS — Homebrew

brew tap 0xShug0/audio-cpp
brew trust 0xShug0/audio-cpp
brew install audio-cpp

Apple builds enable Metal by default. To build from source with Metal explicitly:

scripts/build_metal.sh --target audiocpp_cli
# binary lands at build/macos-metal-release/bin/audiocpp_cli

Windows — prebuilt binaries, no compiler

Official CPU and CUDA zips are on the GitHub Releases page, in three profiles each — fast (native ISA, least portable), balance and portable. If you do not have an NVIDIA GPU, take audiocpp-windows-cpu-balance.zip and you are done: the CPU packages are self-contained.

The CUDA packages are not. Per the 0.6 release notes they are split into a shared runtime plus a profile package, so an NVIDIA user needs two downloads — audiocpp-windows-cuda-runtime.zip and audiocpp-windows-cuda-balance.zip. Grabbing only the profile zip is the most common Windows setup failure on this project. AMD users have community-maintained HIP/ROCm packages with the ROCm runtime bundled, published from a contributor's fork in ROCm 6.4 and ROCm 7.1 tracks.

Linux — build script

Requires GCC 13+, CMake, and the toolchain for whichever backend you want:

scripts/build_linux.sh --backend cuda --target audiocpp_cli --target audiocpp_server
scripts/build_linux.sh --backend vulkan --target audiocpp_cli --target audiocpp_server
scripts/build_linux.sh --backend hip   --target audiocpp_cli --target audiocpp_server
scripts/build_linux.sh --backend cpu   --target audiocpp_cli --target audiocpp_server

Use composite builds if you only want two or three models. Compiling all 49 families is the default and it is slow; --model-set custom links only what you name:

scripts/build_linux.sh --backend cuda --model-set custom \
  --models qwen3_tts,pocket_tts,qwen3_asr --target audiocpp_cli

Docker CUDA and CPU images exist for both CLI and server if you would rather not build at all.

---

First TTS and First Transcript

The CLI is one binary with a --task selector, and the shape is the same for every job.

audiocpp_cli --task <task> --model <path> [--family <name>] [--backend <backend>] [options]

Tasks are vad, asr, diar, sep, gen, tts, clon, vc, s2s, align, vdes, spk and svc. Backends are cpu, cuda, vulkan, metal or best.

Text to speech with a cloned reference voice:

build/bin/audiocpp_cli \
  --task tts \
  --family pocket_tts \
  --model /path/to/models/pocket-tts \
  --backend cuda \
  --text "audio.cpp is running PocketTTS locally." \
  --voice-ref assets/resources/sample.wav \
  --out build/out/pocket_tts.wav

Swap --backend cuda for --backend cpu and the same command works with no GPU. PocketTTS also carries built-in named voices and multiple languages:

build/bin/audiocpp_cli \
  --task tts --family pocket_tts --model /path/to/models/pocket-tts \
  --backend cpu --load-option language=spanish \
  --text "Hola, esta es una prueba corta de Pocket TTS." \
  --voice-id alba --out build/out/pocket_tts_spanish.wav

Transcription:

build/bin/audiocpp_cli \
  --task asr \
  --family qwen3_asr \
  --model /path/to/model \
  --backend cpu \
  --audio assets/resources/sample_16k.wav

Three flags worth knowing on day one: --metrics prints wall time, audio duration and real-time factor so you can measure your own box instead of trusting anybody's table; --inspect prints the configs, weights and capabilities it discovered at a model path; and --batch-text-file runs one offline request per line, which is how you generate an audiobook without a shell loop.

---

The Server and the WebUI

Release 0.6 compiled a SvelteKit WebUI into the server binary, so the browser UI needs no Python, no Node and no Gradio.

audiocpp_server --ui --backend cuda
# then open http://127.0.0.1:8080

That mode gives on-demand model load/unload and temporary browser uploads. Add --ui-management to allow catalogue browsing, downloads and dynamic model switching. The native UI also handles background model preparation, long-text split-and-merge synthesis, a browser-local saved-voice library, microphone recording and near-live ASR input.

For a headless service, write a config and start it:

{
  "host": "127.0.0.1",
  "port": 8080,
  "backend": "cuda",
  "lazy_load": true,
  "models": [
    { "id": "pocket-tts", "family": "pocket_tts", "path": "/path/to/models/pocket-tts", "task": "tts", "mode": "offline" },
    { "id": "qwen3-asr", "family": "qwen3_asr", "path": "/path/to/models/Qwen3-ASR-0.6B", "task": "asr", "mode": "offline" }
  ]
}

The endpoints are GET /health, GET /v1/models, POST /v1/audio/speech, POST /v1/audio/transcriptions and POST /v1/tasks/run — close enough to the OpenAI shape that most existing clients point at it with a base-URL change. If you already run Kokoro-FastAPI as your TTS endpoint, this is the same contract from a binary instead of a container.

One warning from the docs, verbatim in spirit: lazy loading does not unload models after a request. Once a model is used, the server keeps it and its session resident until the process exits. Plan RAM for the sum of every model you expose, not the largest one.

---

Speed, Honestly

The published numbers are the project's own, measured on Ubuntu with CUDA on an RTX 5090, and the README itself flags them as a stale baseline. Take them as direction.

Long-form TTS, same 6,026-character input for every row unless noted:

* VibeVoice is the one row on a different input: the repo notes it uses a 106,310-character, 18,052-word, four-speaker script rather than the shared 6,026-character one. Its wall time is not comparable with the rows above it.

The Supertonic CPU row is the important one on this page: it is the only CPU measurement the repo publishes, and it is the evidence behind "no GPU required". Everything else you would have to measure yourself with --metrics.

Against the Python reference implementations, the project reports one-shot wins of 5.03x (Vevo2), 3.68x (PocketTTS), 2.73x (MioTTS) and 1.83x (Qwen3-TTS), with a warning banner that these were measured at initial release and several paths have moved since. The repo also links a third-party datapoint we did not run ourselves: in the TranscrIA meeting-transcription benchmark on messy French audio, audio.cpp's Nemotron 3.5 ASR is reported to have matched other implementations' word error rate in roughly a quarter of the wall time.

On quantisation, the project argues against its own marketing, which is a good sign. Its own measurements: q8_0 was only about 3.8% faster than the default on Qwen3-TTS and 3.6% on Vevo2 — but cut peak VRAM by about 25% on Qwen3-TTS. Elsewhere it reports ACE-Step failing at runtime under lower precision, and Vevo2 losing measurable output similarity outside fp32. Quantise for memory, not for speed, and validate per model.

---

vs the Python Stack

The trade is deployment simplicity against ecosystem maturity, and nothing else.

When to switch: you need one artefact to deploy; you want TTS and ASR behind a single process; Conda is genuinely the problem you are solving; or you need to run on a Windows box where you cannot install Python. When not to: your current Whisper transcription setup works, or you depend on a Whisper-specific behaviour, or you cannot absorb a breaking change in a project shipping a release every two to three weeks.

For the TTS side of that comparison specifically, our Kokoro TTS setup guide and Piper TTS guide cover the two lightweight Python options this most directly displaces.

---

Licensing

The runtime is Apache 2.0. The weights are not, and that distinction is the whole game.

audio.cpp itself carries an Apache 2.0 licence, copyright ShugoAI LLC 2026. Every model you load through it keeps the licence of its original checkpoint — the conversion repository is tagged simply as "other" and lists dozens of unrelated base models, from ACE-Step to MiniMax-H3 to Qwen3-TTS.

That matters most for voice cloning. A permissive C++ runtime does not make a research-only or non-commercial voice model commercially usable, in exactly the same way that XTTS's licence terms survived every wrapper anyone built around it. Check the upstream model card for each family you actually deploy.

---

Honest Limitations

• No Whisper. Covered above, and worth repeating because it is the single most likely reason someone bounces off this project.
• "No Python" applies to inference, not acquisition. The README concedes that some model preparation jobs call tools/model_manager_v2.py because those packages need a Hugging Face download or a checkpoint conversion. Downloading GGUF files by hand avoids it. The deployed runtime is Python-free regardless.
• CUDA is the first-class backend. The docs say it directly: CPU, Vulkan, Metal and HIP exist for portability and testing, and "performance and model coverage may be lower". Do not assume a family listed in the table has been validated on your backend.
• Coverage is per model, not global. The runtime tags in the supported table differ family by family — some are GGUF 16/Q8, some Q8 only, some F32 only, one (Sortformer diarization) has no GGUF row at all. Check the specific family before you plan around a quant.
• It is two months old and moving weekly. Eight releases between 7 July and 13 August 2026. That is exciting for capability and hostile to anything you need to freeze.
• We have not benchmarked it ourselves. Every performance figure on this page is the project's own or a linked third party's, and is labelled as such. Run --metrics on your hardware before you promise anyone a real-time factor.

---

Sources

• github.com/0xShug0/audio.cpp — README, supported-model table, build scripts, CLI and server docs, performance tables, Apache 2.0 LICENSE
• audio.cpp GitHub Releases — release dates and contents for 0.1.0 through 0.6, and the Windows prebuilt package list
• model_specs/ directory in the repository — the authoritative list of implemented model families
• audio-cpp/audio.cpp-gguf — every GGUF file size quoted on this page
• TranscrIA STT benchmark, linked from the audio.cpp README — third-party ASR wall-time comparison

---

FAQ