实时音频处理

实时音频处理

本节摘要:批处理流水线处理一个文件,实时流水线必须在下一个 20 毫秒到达之前处理好当前的 20 毫秒。每一个对话式 AI、广播工作室、电话机器人都生死系于这条延迟预算。你想让语音助手「感觉活着」——人类对话轮次切换延迟约 230 毫秒(静音到响应),超过 500 毫秒感觉像机器人,超过 1500 毫秒感觉坏了。2026 年一个完整「听 → 理解 → 响应 → 说」回路的预算约 400 毫秒,从麦克风缓冲(20 ms)到喇叭回放(20 ms),中间夹着流式 ASR、LLM 首 token、流式 TTS。Moshi(Kyutai, 2024)做到 200 毫秒全双工,GPT-4o-realtime 约 320 毫秒;而 2022 年的级联流水线还在 2500 毫秒。10 倍提升来自三项技术:处处流式、带部分结果的异步流水线、可中断生成。本节将讲透环形缓冲、VAD 门控、流式 ASR、抢话(barge-in)中断、WebRTC Opus 传输、抖动缓冲,以及线程争用、重采样延迟、TTS 预热、回声消除等常见坑。读完本节,你能为任意实时语音场景设计逐级延迟预算,并避开「缓冲 500 毫秒求保险」「TTS 块太小」「无抖动缓冲」等陷阱。

学习目标

阅读完本节,你应当能够:

1. 说出实时音频的帧/块/窗口概念,理解 20 毫秒(16 kHz 下 320 样本)这个常见选择的由来。
2. 运用环形缓冲、VAD 门控、抖动缓冲 三件套,设计一条不丢帧的实时采集-处理-回放链路。
3. 解释流式 ASR、抢话中断(barge-in)、全双工 的实现要点,以及它们如何把端到端延迟压到亚秒级。
4. 为 2026 年的实时语音应用选择正确的 WebRTC 传输栈(LiveKit、Pion)、流式 ASR、流式 TTS、回声消除。
5. 识别并规避线程争用、重采样延迟、TTS 预热、缓冲过大、TTS 块过小、无抖动缓冲 六类实时坑。

一、问题与直觉

人类对话轮次切换延迟约 230 毫秒(静音到响应)。超过 500 毫秒感觉像机器人,超过 1500 毫秒感觉坏了。2026 年一个完整「听 → 理解 → 响应 → 说」回路的预算:

Moshi(Kyutai, 2024)做到 200 毫秒全双工,GPT-4o-realtime(2024)约 320 毫秒。2022 年的级联流水线还在 2500 毫秒。10 倍提升来自三项技术:(1) 处处流式;(2) 带部分结果的异步流水线;(3) 可中断生成。

帧 / 块 / 窗口

实时音频以固定大小的块流动。常见选择:20 毫秒(16 kHz 下 320 样本)。下游一切都必须跟上这个节奏。

环形缓冲

固定大小的循环缓冲。生产者线程写新帧,消费者线程读。避免在热路径上分配内存。大小 ≈ 最大延迟 × 采样率;一个 2 秒 16 kHz 环 = 32 000 样本。

VAD(语音活动检测)

没人说话时门控下游工作。Silero VAD 4.0(2024)在 CPU 上每 30 毫秒帧 <1 毫秒。webrtcvad 是较老的替代。

流式 ASR

音频到达时即吐部分转录的模型。Parakeet-CTC-0.6B 流式模式(NeMo, 2024)在 320 毫秒延迟下做到 2~5% WER。Whisper-Streaming(Macháček et al., 2023)把 Whisper 分块成近流式,延迟约 2 秒。

抢话中断(barge-in)

当用户在助手说话时插话,你必须 (a) 检测抢话,(b) 停止 TTS,(c) 丢弃剩余 LLM 输出——全部在 100 毫秒内完成,否则用户感觉助手是聋子。

WebRTC Opus 传输

20 毫秒帧,48 kHz,自适应码率 8~128 kbps。浏览器与移动端的标准。LiveKit、Daily.co、Pion 是 2026 年搭语音应用的技术栈。

抖动缓冲

网络包乱序/迟到。抖动缓冲负责重排与平滑;太小 → 听感断续,太大 → 延迟。典型 60~80 毫秒。

常见坑

• 线程争用:Python 的 GIL + 重模型会让音频线程饿死。用 C 回调的音频库(sounddevice、PortAudio),把 Python 踢出热路径。
• 采样率转换延迟:流水线内重采样加 5~20 毫秒。要么预先重采样,要么用零延迟重采样器(PolyPhase、soxr_hq)。
• TTS 预热:即使是 Kokoro 这种快 TTS,首请求也要 100~200 毫秒预热。缓存模型 + 在首次真实轮次前用一次哑运行暖它。
• 回声消除:没有 AEC,TTS 输出会重新进入麦克风,触发 ASR 把机器人自己的声音识别成用户输入。WebRTC AEC3 是开源默认。

💡 延迟预算里每一毫秒都是真金白银。人类对「单向延迟 < 150 毫秒」感知为即时,「150~300 毫秒」感知为流畅,「> 300 毫秒」开始改变对话节奏(人会不自觉地拉长停顿、抢话)。所以实时语音工程的本质,是把每一级的尾延迟(latency)而非吞吐量(throughput)优化到极致——一个每秒能处理 1000 路但每路要等 2 秒的系统,在对话场景里毫无用处。

二、从零实现

第 1 步:环形缓冲

import collections

class RingBuffer:
    def __init__(self, capacity):
        self.buf = collections.deque(maxlen=capacity)
    def write(self, frame):
        self.buf.extend(frame)
    def read(self, n):
        return [self.buf.popleft() for _ in range(min(n, len(self.buf)))]
    def level(self):
        return len(self.buf)
​

容量决定最大缓冲延迟。16 kHz 下 32 000 样本 = 2 秒。

第 2 步:VAD 门控

def simple_energy_vad(frame, threshold=0.01):
    return sum(x * x for x in frame) / len(frame) > threshold ** 2
​

生产环境换成 Silero VAD:

import torch
vad, _ = torch.hub.load("snakers4/silero-vad", "silero_vad")
is_speech = vad(torch.tensor(frame), 16000).item() > 0.5
​

第 3 步:流式 ASR

# 经 NeMo 的 Parakeet-CTC-0.6B 流式
from nemo.collections.asr.models import EncDecCTCModelBPE
asr = EncDecCTCModelBPE.from_pretrained("nvidia/parakeet-ctc-0.6b")
# chunk_ms=320 ms, look_ahead_ms=80 ms
for chunk in audio_stream():
    partial_text = asr.transcribe_streaming(chunk)
    print(partial_text, end="\r")
​

第 4 步:中断处理器

class Dialog:
    def __init__(self):
        self.tts_task = None

    def on_user_speech(self, frame):
        if self.tts_task and not self.tts_task.done():
            self.tts_task.cancel()   # 抢话
        # 然后喂给流式 ASR

    def on_final_user_utterance(self, text):
        self.tts_task = asyncio.create_task(self.reply(text))

    async def reply(self, text):
        async for tts_chunk in llm_then_tts(text):
            speaker.write(tts_chunk)
​

hinges on async I/O 与可取消的 TTS 流。WebRTC 在音频轨道上 peerconnection.stop() 是经典做法。

设计要点:抢话中断的难点不是「停 TTS」,而是「丢 LLM 余量」——LLM 通常已在生成后续 token,如果不及时取消,它会把已经被用户打断的话继续说完再喂给 TTS,造成延迟债务。所以 tts_task.cancel() 必须连带取消上游的 LLM 流式生成,这是一条贯穿整条异步链路的取消传播。

三、框架对比

2026 年技术栈:

⚠️ 五类坑:① 缓冲 500 毫秒求保险——缓冲就是你的延迟下限,要缩小它;② 不固定线程——音频回调跑在比 UI 还低的优先级线程上,负载一来就出爆音;③ TTS 块太小——小于 200 毫秒的块会让声码器瑕疵可闻,320 毫秒是甜点;④ 无抖动缓冲——真实网络有抖动,不平滑就会爆音;⑤ 单次错误处理——音频流水线必须抗崩,一次异常就杀死整个会话。

四、可复用产物

本节产出技能文档(原课程 outputs/skill-realtime-designer.md),为实时音频流水线设计逐级具体延迟预算。模板:

五、练习

1. 基础:运行 code/main.py。它模拟环形缓冲 + 能量 VAD,对一段假的 10 秒流打印逐级延迟。

2. 进阶:用 sounddevice 搭一个直通回路,以 20 毫秒帧处理麦克风,每帧打印 VAD 状态。

3. 挑战:用 aiortc 搭全双工回声测试:浏览器 → WebRTC → Python → WebRTC → 浏览器。用 1 kHz 脉冲测玻璃到玻璃延迟。

本节要点回顾

1. 实时 = 在下一个 20 毫秒到达前处理好当前的 20 毫秒,延迟预算而非吞吐量是优化的核心。
2. 人类轮次切换约 230 ms,>500 ms 像机器人,>1500 ms 像坏了;2026 年端到端预算约 400 ms。
3. Moshi 200 ms 全双工、GPT-4o-realtime 320 ms,10 倍提升来自处处流式 + 异步部分结果 + 可中断生成。
4. 环形缓冲固定大小、避免热路径分配,容量即最大缓冲延迟。
5. Silero VAD 4.0 每帧 <1 ms,是门控下游、省算力的关键。
6. 流式 ASR(Parakeet-CTC 320 ms 延迟、Whisper-Streaming 2 s)决定延迟下限。
7. 抢话中断要同时停 TTS + 取消 LLM 余量,整条异步链路取消传播,<100 ms 内完成。
8. WebRTC Opus + 抖动缓冲 60~80 ms + AEC3 是传输层的 2026 标配。
9. 六类坑:缓冲过大、线程优先级低、TTS 块太小(<200 ms)、无抖动缓冲、重采样延迟、单次错误即崩。

下一节是本章的毕业项目——把 VAD、流式 ASR、LLM、流式 TTS、抢话中断全部接成一条端到端的语音助手流水线,目标端到端延迟 < 1 秒。