100 Models in 100 Days! 🎯

[0xShug0]

Launched on June 25, 2026, audio.cpp is getting close to supporting 100 audio model families in its first 100 days.

15 days left.

We’re almost there — and we’d love your help getting across the finish line.

If there’s an audio model you’d like to see in audio.cpp, pick one up and submit a PR! TTS, ASR, music, voice conversion, diarization, source separation, audio understanding, or anything else involving audio is welcome.

Let’s make it 100 in 100.

Current models under development or testing

Model	Category
LiveAvatar	Audio to Video
AuK	TTS
Reuse	Tool
PiperTTS	TTS
KittenTTS	TTS

Candidate models

For models crossed out ―: I will not impl these models myself, but contributions are welcome.

Model
smart turn
Sidon
gigaam v3
Moss-TTS-1.5 (https://huggingface.co/OpenMOSS-Team/MOSS-TTS-v1.5)
Orpheus-TTS
kugelaudio-0-open
LongCat-AudioDiT
GPT-SoVits (reference: https://github.com/qq1980-cn/GPT-SoVits-mcp)
NVIDIA VoiceChat-11B

The default branch is main, and new models near release will be under the the dev branch.

[ownia]

Hi @0xShug0, I noticed that the Huggingface audio-cpp/audio.cpp-gguf repository has uploaded dots.tts (MF/SOAR) GGUF files: https://huggingface.co/audio-cpp/audio.cpp-gguf/commit/4c9a3098d552a0f3d9b2adc11638a11022c07d7e. Does this mean that official support for dots.tts will be available soon?

[0xShug0]

@ownia Yes, stay tuned! I got a little distracted by VibeVoice on iOS and MiniMax H3 Audio, so the new release will be delayed a bit. I also want to fully test the new UI and include it in the next release.

[0xShug0]

@ownia dots.tts is in the dev branch now and you can try it.

[YJX-Research]

Hi @0xShug0, great to see ControlFoley on the audio.cpp roadmap!

I'm one of the ControlFoley authors and maintainers. Really appreciate you working on the port.

If anything about the architecture, checkpoints, preprocessing/postprocessing, or inference pipeline is unclear, please feel free to ping me. I'd also be happy to provide reference outputs or fixed test cases to help verify that the C++ implementation matches the official implementation.

Looking forward to seeing ControlFoley running in audio.cpp — happy to help make the integration easier!

[0xShug0]

Hi @0xShug0, great to see ControlFoley on the audio.cpp roadmap!

I'm one of the ControlFoley authors and maintainers. Really appreciate you working on the port.

If anything about the architecture, checkpoints, preprocessing/postprocessing, or inference pipeline is unclear, please feel free to ping me. I'd also be happy to provide reference outputs or fixed test cases to help verify that the C++ implementation matches the official implementation.

Looking forward to seeing ControlFoley running in audio.cpp — happy to help make the integration easier!

@YJX-Research Thanks for reaching out! I saw the model yesterday and immediately decided to work on it. It’s a great model with a lot of potential.

I was just about to connect with your team members (based on the paper author list) on LinkedIn. 😄

[YJX-Research]

@0xShug0 Thanks! We have just refreshed the official ControlFoley repository with a complete set of new demos for all supported tasks:

https://github.com/xiaomi-research/controlfoley/tree/main/examples

The examples cover V2A, TV2A, TC-V2A, AC-V2A, and T2A, including input videos, text prompts or reference audio, generated WAV files, and muxed video previews. I hope these materials can help with integration testing and qualitative output verification during the audio.cpp port.

We would be very happy to fully support your work on the integration. Please feel free to reach out at any time if you need help with the model architecture, checkpoints, preprocessing or postprocessing, inference pipeline, reference outputs, test cases, or anything else that could make the port easier.

I’m not currently active on LinkedIn, but you can reach me directly at yangjianxuan@xiaomi.com or mention me here on GitHub.

[0xShug0]

@YJX-Research Call it a day :). Pushed ControlFoley to dev (along with two other leaked models). The GGUF has also been uploaded.

Good: the model contributes many new building blocks (OpenCLIP etc)

Ugly: The video preprocessing path is still not clean, and it is the main slow component compared with Python. It is not fully audio.cpp-native today: the current implementation calls external libav .so to process video. That works, but it can limit where ControlFoley is usable and how easy it is to package or deploy. A vendored library may be a cleaner approach, but I’d prefer it to be lightweight, portable, and scoped to ControlFoley only if included in the repo. I haven’t found a good candidate yet.

What’s next: further memory and performance optimizations, quantization experiments, and code refactoring.

Feel free to test it and submit PRs if you want to optimize the code or spot any logic mismatches.

Case	wav cosine	log-mel cosine	frames
t2a	0.999793318892	0.999959774036	match
tv2a	0.248862197656	0.995960908859	match
tc_v2a	0.131512452694	0.996468491646	match
ac_v2a	0.375907529980	0.995561132600	match
v2a	0.271179424496	0.988865889302	match

(For v2a, the original path had ~0.99 log-mel parity with Python. After optimizing the video preprocessing path, parity regressed. I have not investigated the regression root cause in detail yet).

[YJX-Research]

@0xShug0 This is impressively fast. Thank you for getting all five ControlFoley tasks running in dev, uploading the GGUF, and sharing the Python/C++ parity results.

The matching frame counts and high log-mel cosine scores look like a strong first milestone. We will test the dev implementation and review it against the official Python preprocessing pipeline, particularly the V2A parity regression you observed.

If we identify any logic mismatch or optimization opportunity related to the official implementation, we will share reproducible findings and submit a PR where appropriate. We are also happy to clarify the official pipeline if anything is unclear during further parity testing.

We also understand the portability and packaging concern around the external libav dependency. Thanks again for the rapid port. We will follow up once we have concrete findings.

[ClayShoaf]

Looking forward to the Breeze implementation.

Also, surprised Kokoro didn't meet your bar. That is my current go-to when I want a quick generation. It sounds, by far, the best in that size class. I was hoping it would be available here.

[0xShug0]

Looking forward to the Breeze implementation.

Also, surprised Kokoro didn't meet your bar. That is my current go-to when I want a quick generation. It sounds, by far, the best in that size class. I was hoping it would be available here.

It was my kokoro impl on CPU didn't meet the performance bar...it's slower than Python.