折腾记（二）：接入火山引擎实时语音 API，家庭语音助手体验直接拉满

ladydd

05 Jun 2026 — 9 min read

接上篇

上一篇用全开源组件（Whisper + Hermes + Edge-TTS）搭了个语音助手，能跑，但体验就是"能用"二字：

中文识别只有 70 分，方言基本歇菜
英文唤醒词"Alexa"喊着别扭
说完到回复要等 4-8 秒
它说话的时候你插不了嘴

这些问题靠堆开源组件很难根治。于是我去试了火山引擎（字节跳动）的语音服务，结果直接换了条路。

这篇分两段：先讲怎么用火山引擎的 ASR/TTS 替换掉开源组件（小改），再讲怎么上端到端实时语音模型（大改）。

第一段：先把 ASR 和 TTS 换成火山引擎

为什么换

我用豆包输入法的时候发现它语音识别准得离谱。一查，豆包用的就是字节自家的火山引擎 Seed-ASR。开通后有免费额度（语音识别送 20 小时、语音合成送 2 万字符、端到端实时语音送 100 万 tokens），够玩很久。

Seed-ASR（语音识别）

火山的录音文件识别是 submit + query 两步：先提交音频，再轮询结果。

import requests, base64, uuid

# 提交
req_id = str(uuid.uuid4())
resp = requests.post(
    "https://openspeech.bytedance.com/api/v3/auc/bigmodel/submit",
    headers={
        "X-Api-Key": API_KEY,
        "X-Api-Resource-Id": "volc.seedasr.auc",
        "X-Api-Request-Id": req_id,
        "X-Api-Sequence": "-1",
    },
    json={
        "user": {"uid": "voice-assistant"},
        "audio": {"data": base64.b64encode(wav).decode(),
                  "format": "wav", "rate": 16000, "bits": 16, "channel": 1},
        "request": {"model_name": "bigmodel", "enable_punc": True},
    },
)

# 用同一个 req_id 轮询结果

我拿上篇 Whisper 识别得乱七八糟的同一段录音测试，火山直接给出 "你好你好你好，我是一个机器人，你好你" —— 带标点、断句准确。后来实测说陕西话它都基本全对。识别这块直接降维打击。

Seed-TTS（语音合成）+ 陕西话

火山的 TTS 音色库里有个 Vivi 2.0（zh_female_vv_uranus_bigtts），明确支持四川、陕西、东北三种方言。

调用走 HTTP Chunked 流式接口，关键是 additions.explicit_dialect：

payload = {
    "user": {"uid": "voice-assistant"},
    "req_params": {
        "text": "兄弟，你说啥呢，我没听清楚，你再说一遍嘛。",
        "speaker": "zh_female_vv_uranus_bigtts",
        "audio_params": {"format": "mp3", "sample_rate": 24000},
        "additions": json.dumps({"explicit_dialect": "shaanxi"}),
    },
}
# Resource-Id 用 seed-tts-2.0

这里踩了个坑：Resource-Id 一开始乱填（volc.bigtts.default 之类），一直报 resource not granted。查文档才知道要用 seed-tts-2.0（对应语音合成 2.0 模型）。

播出来的陕西话比 edge-tts 那个自然太多，字节的语音技术确实强。

到这一步，开源方案的两个最弱环节（识别、合成）都换成了火山，体验提升明显。但架构还是分步的，延迟问题没解决，唤醒词问题也还在。

第二段：上端到端实时语音模型

什么是"端到端"

传统链路是分步流水线：

录音 → STT → LLM → TTS → 播放

每步都有延迟，串起来就慢。

端到端实时语音是一个模型从头包到尾：

麦克风音频流 ←→ 端到端大模型 ←→ 音响音频流

音频流进去，音频流出来。它自己听、自己想、自己说。延迟极低，内置 VAD 和打断。就是 OpenAI Realtime API、GPT-4o 语音模式那一类东西，火山也有。

代价：换模型 + 失去 Hermes

用这个的代价很明确：LLM 变成字节的豆包模型，不再是我的 Hermes/DeepSeek。 我的服务器只负责"搬运音频"——把麦克风音频推上去、把返回的音频播出来，所有"智能"都在云端。

它支持 system_role、speaking_style、bot_name 定制人设，但没法塞自定义记忆/知识库。这是黑盒的代价。

WebSocket 二进制协议（最硬的骨头）

这个 API 不是标准 JSON over WebSocket，而是自定义二进制协议。一帧的结构：

[4字节 header][可选 event_id][可选 session_id][4字节 payload长度][payload]

header 4 字节描述协议版本、消息类型、序列化方式、压缩
payload 可以是 JSON（文本事件）或者裸音频字节（音频事件）

文本事件帧的 header 是 [0x11, 0x14, 0x10, 0x00]，音频事件帧是 [0x11, 0x24, 0x00, 0x00]（差别在消息类型和序列化方式）。

手写帧组装/解析：

def build_client_event(event_id, session_id=None, payload=None):
    header = bytes([0x11, 0x14, 0x10, 0x00])
    event_bytes = struct.pack(">I", event_id)
    session_bytes = b""
    if session_id and event_id >= 100:
        sid = session_id.encode()
        session_bytes = struct.pack(">I", len(sid)) + sid
    data = json.dumps(payload, ensure_ascii=False).encode() if payload else b"{}"
    return header + event_bytes + session_bytes + struct.pack(">I", len(data)) + data

调试这个二进制协议是整个项目最磨人的部分，差一个字节就连不上。建议直接抄官方 Python demo 的字节布局。

鉴权

端到端用的是旧版鉴权（App ID + Access Token），跟前面 ASR/TTS 的新版 API Key 不一样，别搞混：

headers = {
    "X-Api-App-ID": APP_ID,
    "X-Api-Access-Key": ACCESS_KEY,
    "X-Api-Resource-Id": "volc.speech.dialog",
    "X-Api-App-Key": "PlgvMymc7f3tQnJ6",  # 固定值
}

会话流程

StartConnection(1) → StartSession(100, 配置方言/人设)
  → 持续推音频(200) ←→ 持续收事件

StartSession 里配置陕西话和人设：

{
    "tts": {
        "speaker": "zh_female_vv_jupiter_bigtts",
        "extra": {"explicit_dialect": "shaanxi"},
        "audio_config": {"format": "pcm_s16le", "sample_rate": 24000},
    },
    "asr": {"audio_info": {"format": "pcm", "sample_rate": 16000, "channel": 1}},
    "dialog": {
        "bot_name": "小陕",
        "system_role": "你是一个热情的家庭语音助手，说话用陕西方言风格...",
        "dialog_id": "home-assistant-main",  # 固定ID，断线重连恢复上下文
        "extra": {"model": "1.2.1.1", "input_mod": "keep_alive"},
    },
}

收发并发

用 asyncio 同时跑"发音频"和"收事件"两个协程：

await asyncio.gather(
    self.send_audio(),      # 麦克风 → 火山，20ms一包
    self.receive_events(),  # 火山 → 音响
)

服务端返回的关键事件：

451 ASRResponse — 识别出你说的文字
352 TTSResponse — 返回的音频数据（裸 PCM）
450 ASRInfo — 检测到你开始说话（可用来做打断）

老朋友：采样率坑又来了

跟上篇一模一样：无线麦只支持 48kHz，服务端要 16kHz。录 48kHz 降采样到 16kHz：

chunk_16k = chunk[::3]

播放端服务端返回 24kHz PCM，声卡不直接支持，用 aplay 的 plughw 让 ALSA 自动转换。

播放卡顿

第一版播放每收一小块音频就启一个 aplay 进程，进程间有间隙，听着一卡一卡。改成一个常驻 aplay 进程，音频流式写进它的 stdin：

self._aplay_proc = subprocess.Popen(
    ["aplay", "-D", "plughw:0,0", "-f", "S16_LE", "-r", "24000", "-c", "1", "-t", "raw"],
    stdin=subprocess.PIPE, stderr=subprocess.DEVNULL,
)
# 收到音频就写
self._aplay_proc.stdin.write(audio_bytes)
self._aplay_proc.stdin.flush()

流畅了。

让它永久挂着：systemd 服务

我想让它开机自启、崩了自动重启、断线自动重连，于是做成 systemd 服务。

[Service]
Type=simple
User=ladydd
Group=ladydd
SupplementaryGroups=audio
WorkingDirectory=/home/ladydd/voice-doubao
ExecStart=/path/to/venv/bin/python main.py
Restart=always
RestartSec=10

这里有个隐蔽的坑卡了我很久：服务跑起来了，麦克风也识别了，识别文字也出来了、tokens 也扣了，但就是没声音。

折腾半天发现是 systemd 服务的音频权限问题。我一开始写 Group=audio，但这样进程的主组变了，反而有别的问题。正确写法是主组保持用户自己的组，audio 作为附加组：

Group=ladydd
SupplementaryGroups=audio

改完音响立刻出声。

教训：systemd 服务要访问音频设备，用 SupplementaryGroups=audio，不是 Group=audio。

自动重连

端到端模型超过 10 分钟没对话，服务端会主动断开（错误码 45000003）。所以挂机必须有重连：

while True:
    try:
        await self._run_session()  # 一次完整会话
    except Exception as e:
        print(f"连接异常: {e}")
    # 断了就重连
    self.session_id = str(uuid.uuid4())
    await asyncio.sleep(5)

配合固定的 dialog_id，重连后还能恢复最近 20 轮上下文。

管理命令：

sudo systemctl status voice-doubao    # 状态
sudo systemctl restart voice-doubao   # 重启
journalctl -u voice-doubao -f         # 实时日志

计费：挂着不要钱

按 tokens 计费，不按连接时长。挂着不说话不扣钱，只有实际对话才消耗。免费额度 100 万 tokens，按每轮约 1000-4000 tokens 算，够用很久。

没解决的问题：环境噪音

端到端方案体验确实好——直接说话、实时回复、陕西话、能打断。但有个我没解决的硬伤：

它没有唤醒词，靠 VAD 检测人声触发。 这意味着家里只要有别人说话、电视声音，它都会当成你在跟它对话。我看日志里它把电视里的内容都识别进去、还自顾自回复，token 哗哗烧。

📝 你说: 就是买这药的人知道有虫，销量越来越高...（电视里的声音）
📊 本轮消耗: 4175 tokens

火山的端到端模型设计场景是"一对一安静环境"（打电话、戴耳机），不是开放式客厅。要在嘈杂家庭环境用，还得在客户端加一层唤醒词门禁——平时不推音频，喊唤醒词才开始推。这个留作后续。

两套方案对比

	全开源（上篇）	火山端到端（本篇）
延迟	4-8 秒	<1 秒
识别准确率	70 分	95 分（懂方言）
唤醒	英文唤醒词，别扭	无（VAD，怕吵）
打断	不支持	支持
LLM	自己的 Hermes/DeepSeek	字节豆包，黑盒
记忆	持久记忆+技能	最近20轮上下文
隐私	基本内网	音频上云
成本	全免费	有额度，超出付费
代码复杂度	多组件拼装	一个 WebSocket（但协议硬核）

我的结论

两套我都留着，因为它们定位不同：

火山端到端 → 日常闲聊、即时问答，体验好，当个能说话的玩具/助手
全开源 + Hermes → 要记忆、要接日程提醒/智能家居/自定义技能时用，可控可扩展

理想的最终形态可能是把两者缝起来：用火山的实时语音做"听和说"的交互层，用 Hermes 做"想和记"的大脑层——火山识别出文字转发给 Hermes，Hermes 的回复再用火山 TTS 说出来。但那是另一个坑了。

至于最开始那块 ESP32-S3 —— 它现在还在抽屉里躺着，等我哪天想做无线拾音终端再翻出来。这个项目教我的最大一课是：别为了用某个炫酷的硬件，而绕开最简单的解法。

两套方案代码均已开源，包含完整实现、systemd 配置和这一路的踩坑记录。