I Built a 220-Line Vocalinux Bridge. A Day Later, I Found audio.cpp

On September 10, I published the 220-line local server I had written to connect GigaAM to Vocalinux. The next morning I stumbled across audio.cpp, an all-in-one C++ runtime with the same /v1/audio/transcriptions endpoint and a server already built in. For a moment it looked as if I had reinvented the wheel, but there is one important catch: audio.cpp does not support GigaAM yet.

1. The timing was almost ridiculous

audio.cpp 0.7.3 was released on September 7, 2026. My Vocalinux, transcribe.cpp, and GigaAM article went live on September 10. I found audio.cpp on September 11, after spending the previous evening solving one narrow part of a problem that this new project tackles on a much larger scale.

audio.cpp is only a few months old. Its first releases appeared on June 25, 2026, and version 0.7 on August 26 already listed 62 model families and more than 85 variants. It covers ASR, TTS, voice cloning, VAD, diarization, source separation, music generation, and audio editing. transcribe.cpp covers 16 families and 60-plus variants; audio.cpp is trying to put nearly the entire local AI audio toolbox behind one C++ runtime.

2. The useful coincidence is the API

This is the part that made me stop and look twice. Vocalinux records 16 kHz, mono, 16-bit PCM audio, wraps it in a WAV file, and sends it to POST /v1/audio/transcriptions. The audio.cpp server accepts the same OpenAI-style request: a file, a model, an optional language, and a JSON response with text.

Vocalinux
  -> POST 127.0.0.1:8080/v1/audio/transcriptions
  -> audiocpp_server
  -> Qwen3-ASR GGUF
  -> Vulkan / Intel Iris Xe

For any model supported by audio.cpp, I can connect Vocalinux directly to that server. The settings are simple: enable Remote Server, use http://127.0.0.1:8080, select the OpenAI/FunASR endpoint, and set the model to qwen3-asr. My 220 lines of server code, the Python bindings, and the manual call into libtranscribe.so all disappear from that path.

3. There is one catch: audio.cpp cannot run GigaAM

Unfortunately, I cannot point audiocpp_server at gigaam-v3-e2e-rnnt-Q8_0.gguf and delete yesterday’s code. GGUF is a file format, not a universal model interface; the runtime still has to understand the model’s architecture and decoder. GigaAM is not in the audio.cpp 0.7.3 supported or community tables, so its 261 MB checkpoint has no loader there.

The official Qwen3-ASR 0.6B Q8 package is 1.15 GB, about 4.4 times larger than my GigaAM model. It supports 30 languages, including Russian, and audio.cpp can run it in streaming mode. GigaAM still looks like the better lightweight option for short Russian dictation. Qwen3-ASR may do better with mixed Russian-English developer speech, which is exactly what I want to test.

So no, I cannot delete yesterday’s server yet. audio.cpp can replace it only if I replace GigaAM too. The setup from my previous Vocalinux experiment is still the only one of these two options that runs the 261 MB GigaAM model.

4. For now, I am going to run both servers

For the next test, I will leave GigaAM running on port 8765 and start audio.cpp beside it on port 8080. Vocalinux already stores the remote URL and model name in its configuration, so switching between them does not require another patch. GigaAM can remain my everyday Russian dictation engine while audio.cpp becomes the place where I try multilingual models.

{
  "host": "127.0.0.1",
  "port": 8080,
  "backend": "vulkan",
  "lazy_load": false,
  "models": [{
    "id": "qwen3-asr",
    "family": "qwen3_asr",
    "path": "/opt/audio.cpp/models/qwen3-asr-0.6b-q8_0.gguf",
    "task": "asr",
    "mode": "offline"
  }]
}

There are ready-made Ubuntu x64 binaries for CPU and Vulkan. My laptop runs Debian, so I will start with a small source build containing only Qwen3-ASR: scripts/build_linux.sh --backend vulkan --model-set custom --models qwen3_asr --target audiocpp_server. It requires GCC 13 or newer, CMake, and the Vulkan toolchain, but the result is a complete API server with no Python adapter to maintain.

5. The real test is 50 recordings, not four polished demos

audio.cpp reports impressive numbers: some TTS paths run 1.8 to 8 times faster than their Python versions, and tested Q8 packages cut peak VRAM by as much as 37% on specific models. Those are the project’s CUDA results, not mine, and they say nothing about Qwen3-ASR on Intel Iris Xe through Vulkan. The only useful answer is to run the same audio through both setups.

My test set will contain 50 identical WAV recordings: 25 Russian sentences, 15 mixed Russian-English sentences, and 10 samples with library names, shell commands, and code vocabulary. I will run every file through GigaAM and Qwen3-ASR at least five times after one cold start. The useful numbers are WER, punctuation mistakes, cold and warm latency, RAM use, and peak GPU memory.

I already have a baseline from the first article: GigaAM processed an 11-second clip in 1.2247 seconds, almost 9 times faster than real time, while the loaded service used about 329 MB of RAM. If Qwen3 is better with bilingual technical speech but needs four or five times more memory, neither model wins outright. I will simply have two good tools for different kinds of dictation.

6. audio.cpp could grow beyond this dictation experiment

Vocalinux only needs transcription, but audio.cpp goes much further. The same binary provides /v1/audio/speech, detailed transcripts with timestamps and speaker labels, and experimental JSON pipelines. Version 0.7.3 added /v1/audio/transcriptions/details; the wider runtime also includes VAD, diarization for up to four speakers, forced alignment, and source separation.

This is where the project becomes interesting beyond voice typing. I have already covered ACE-Step 1.5 as a local alternative to cloud music generation in Ravlik’s AI Experiments section, and that model family is now part of the audio.cpp ecosystem too. One C++ runtime, one model manager, and one API would be much easier to live with than a separate Python environment for every audio experiment.

There is still an asterisk next to “one runtime.” Inference and the built-in WebUI are native, but some model downloads and conversions can call the project’s Python model manager. CUDA is also the best-optimized backend. Vulkan, Metal, HIP, and CPU are supported, but some models may be slower or less polished there.

7. A local speech API should stay local

For this setup I will bind audio.cpp to 127.0.0.1, not 0.0.0.0. That keeps port 8080 out of reach of every other machine on the network. Vocalinux gives a transcription request 30 seconds, so I will also load the model at startup instead of making the first spoken phrase wait for a cold load.

If I later move the server to a desktop or a home GPU box, it will need HTTPS and authentication. Vocalinux sends the original WAV file, not harmless tokens, so anyone intercepting the request gets the actual recording. Localhost is enough for this experiment; LAN or mobile access is a different security job.

So no, I did not waste yesterday evening

I could have patched Vocalinux and tied it directly to GigaAM. Instead, I left Vocalinux alone and put an ordinary HTTP API in between. Finding audio.cpp the next morning confirmed that this was the right choice: Vocalinux does not care which inference engine sits behind that endpoint.

The plan is simple. I will keep GigaAM on 8765, run Qwen3-ASR through audio.cpp on 8080, and compare 50 recordings on the same Intel Iris Xe laptop. If audio.cpp eventually adds GigaAM, I can delete those 220 Python lines. Until then, they solve a real problem, and the project I found one day later shows that the whole setup was pointed in the right direction.

How this was checked: release dates, model lists, API formats, build options, and backend caveats were verified on September 11, 2026 against the official audio.cpp and Vocalinux repositories and the audio.cpp GGUF collection on Hugging Face. The Intel Iris Xe installation and 50-recording comparison are presented as the next test plan, not as completed results.