Bailing (百聆): A CPU-Only Voice Loop Built From FunASR, Silero-VAD, DeepSeek and OpenClaw
百聆 是一个类似GPT-4o的语音对话机器人,通过ASR+LLM+TTS实现,集成DeepSeek R1等优秀大模型,接入openClaw,真正的个人语音助手,时延低至800ms,Mac等低配置也可运行,支持打断
At a glance
- What is it?
- Bailing chains four open components into a single speech-to-speech loop that the README claims runs without a GPU at roughly 800 ms end-to-end latency. The interesting part is not the model list but the barge-in state machine and the OpenClaw tool layer bolted onto it.
- Who is it for?
- Adopt Bailing if you want a readable, MIT-licensed reference implementation of a barge-in-capable voice loop that you can run on a Mac without a discrete GPU, and you are comfortable editing config/config.yaml, dropping SenseVoiceSmall into models/SenseVoiceSmall, and wiring an OpenClaw auth token into config/.env yourself.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 163 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Bailing fills: a full voice loop without a GPU
Most open voice assistants assume you have a discrete GPU sitting idle. Bailing's stated goal is the opposite: the README describes it as aiming for GPT-4o-like conversation on edge devices and low-resource environments, explicitly without a GPU. The target reader is someone who wants to speak to a model and hear it answer, on a laptop, with the whole pipeline assembled from parts they can swap out. That framing matters because it changes what the project optimizes for. A GPU-backed stack can afford a large local LLM; Bailing instead leans on a hosted model (DeepSeek by default, with OpenAI, Qwen, Gemini and 01yi listed as alternatives in the README) and spends its local compute budget on ASR and TTS. The README also lists a set of capabilities beyond plain chat: memory of user preferences and history, tool calling, task management, and OpenClaw as the execution layer for multi-step work. Whether all of those are equally mature is a separate question, and the README does not say which ones are complete.
The state machine behind interrupt support
The genuinely specific part of the README is a four-row table describing how playback state and speech detection combine. When the player is running and the user is not speaking, that is normal operation. When the player is running and the user does speak, that is the interrupt case. When the player is idle and the user is silent, that is also normal. When the player is idle and the user speaks, VAD decides and ASR transcribes. That table is the whole barge-in design in miniature, and it tells you what the project considers the hard case: audio is still coming out of the speaker while the microphone is live, so the system has to decide whether incoming energy is the user talking over the assistant or the assistant's own output bleeding back. The README names a Robot component as responsible for task and memory management, for handling interrupt requests, and for coordinating the modules. It does not document how echo cancellation is handled, and the material does not say whether the interrupt path depends on keyword detection, raw VAD energy, or both. The README mentions configurable interrupt strategy with keyword and voice interruption, so both exist, but the selection mechanism is not described in the supplied text.
Four modules, four vendors, one config file
The pipeline is FunASR for speech recognition, silero-vad for voice activity detection, DeepSeek for generation, and a choice of edge-tts, Kokoro-82M, ChatTTS or the macOS say command for synthesis. The README calls the design modular so each stage can be replaced. That is a real advantage in a fast-moving area, and it is also the main integration cost: four upstream projects, four release cadences, four sets of dependencies. The install instructions reflect that, requiring both the project's own requirements.txt and a second file at third_party/OpenManus/requirements.txt. Note the naming inconsistency in the documentation. The install steps and the tool table refer to OpenManus and to openclaw, and the README's prose describes OpenClaw as the core tool-calling engine for complex tasks, external tool orchestration and higher-level agent behaviour. The supplied material does not explain whether these are the same component under different names or two separate things, and I cannot resolve that from what is here. Anyone evaluating this should check the third_party directory layout before assuming a single dependency.
Getting it running: the actual commands and files
The README gives a concrete sequence. Clone the repository, then install dependencies with pip install -r requirements.txt followed by pip install -r third_party/OpenManus/requirements.txt. Python 3.12 or higher is the stated requirement. Configuration happens in three places. First, config/config.yaml holds ASR and LLM settings. Second, SenseVoiceSmall must be downloaded into models/SenseVoiceSmall from the FunAudioLLM Hugging Face repository. Third, an API key is needed, obtained from the DeepSeek platform, with the README noting OpenAI, Qwen, Gemini and 01yi as alternatives. For the AIGC path, /third_party/OpenManus/config/config.toml needs model, base_url and api_key set, and the README flags this path as under test and suggests falling back to tag v0.0.1 or v0.0.2 if it does not work. For OpenClaw, config/.env needs an auth permission configured. Two run modes are documented: local, with cd server then python server.py, optionally skipped, then python main.py; and server mode, which the README recommends, where you generate a self-signed certificate with openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes, start python server.py from the repository root, and open http://localhost:8000 in a browser. The README says server mode enables conversation from a mobile device.
Where the documentation stops being specific
The 800 ms end-to-end latency claim appears in the project description and in the README without a stated measurement method, hardware baseline, or breakdown by stage. That is not a reason to disbelieve it, but it is a reason not to plan around it. ASR, network round-trip to a hosted LLM, and TTS each contribute, and only one of those is under the project's control. The memory feature is described in terms of capability (remembering preferences and history) rather than mechanism: no storage format, no retrieval strategy, no retention policy appears in the supplied material. The same is true of task management, which is described as tracking progress, setting reminders and providing dynamic updates, with a schedule_task tool example but no description of how tasks persist across restarts. The tool table is more concrete, listing get_weather, ielts_speaking_practice, get_day_of_week, schedule_task, open_application, web_search and aigc, each with an example utterance. Two of those are macOS-specific: open_application launches a named app on a Mac, and macOS say is one of the TTS options. On Linux or Windows, the tool surface is smaller than the table suggests.
The disclaimer is the strongest signal in the repository
Bailing ships under the MIT licence, which permits use, modification and redistribution provided the original licence notice is retained. That is permissive and unremarkable. What is unusual is the disclaimer that sits below it. It states that the project is intended for personal learning and research only, that it is not suitable for commercial use or production environments, that using it may cause data loss, system failure or other problems, that the authors accept no liability for any loss or damage, and that no technical support or warranty of any kind is provided. Read those two documents together and you have a permissive licence paired with an explicit statement that production use is out of scope. The licence grants you the legal permission; the disclaimer tells you the authors are not standing behind it. For a personal assistant that may hold conversation history and schedule reminders, the data loss warning is worth taking literally: the material does not describe any backup or export path for whatever the memory feature stores.
Alternatives and the actual difference in approach
The most direct comparison is Home Assistant's voice pipeline, which also chains wake word, speech-to-text, a conversation agent and text-to-speech, and which also runs on modest hardware. The difference is architectural intent. Home Assistant's pipeline exists to control devices and is bound to a home-automation entity model, with the assistant as one component in a larger system that already has state, persistence and a UI. Bailing is a standalone loop with no device model underneath it; its extension point is tool calling through OpenClaw rather than entity control. A second comparison is a hosted assistant API with a speech interface, where the entire chain runs behind one vendor endpoint. That removes the four-dependency integration problem and the local model download, at the cost of the modularity the README treats as a feature and at the cost of running offline. Bailing's position is the middle: hosted LLM, local ASR and TTS, self-hosted server, MIT licence. If your requirement is an assistant that controls your lights, Bailing is the wrong shape. If your requirement is a voice loop you can read and modify end to end, the four-module split is the point.
Maintenance cost and what to check before you commit
The release history shows v0.0.1 in October 2024, v0.0.2 in March 2025 and v0.0.3 in May 2025, with the last push to the repository in April 2026. Three releases across roughly seven months of tagged work, then a gap, is a cadence you should weigh against the number of upstream projects the install depends on. FunASR, silero-vad, ChatTTS, Kokoro-82M and the OpenManus or OpenClaw component all move independently, and a breaking change in any one of them lands on you, not on the maintainer. The README's own fallback advice, to drop back to tag v0.0.1 or v0.0.2 when the AIGC path misbehaves, is an admission that the newer path is not stable. The practical checks before adopting: confirm the model directory path matches models/SenseVoiceSmall exactly, since a mismatch there fails before any of the interesting code runs; decide up front whether you need the AIGC and OpenClaw paths at all, because skipping them removes the third_party requirements file and the config.toml and .env steps entirely; and measure the latency yourself on the machine you intend to use, because the README's number carries no hardware context. The roadmap lists voice wake-up as the one unchecked item, so wake-word behaviour is not something to expect today.
Editorial conclusion
Adopt Bailing if you want a readable, MIT-licensed reference implementation of a barge-in-capable voice loop that you can run on a Mac without a discrete GPU, and you are comfortable editing config/config.yaml, dropping SenseVoiceSmall into models/SenseVoiceSmall, and wiring an OpenClaw auth token into config/.env yourself. Do not adopt it if you need a supported product: the README states the project is for personal learning and research and not for commercial or production use, and it offers no technical support or warranty. Before committing, verify the 800 ms figure on your own hardware, confirm which tag you are actually installing (the README warns the generic AIGC path is under test and points back to v0.0.1 or v0.0.2 if it fails), and check whether the model you plan to use is reachable from your network.
Community notes