阅读导航#

• 第三篇：从按键启动到云端语音回答
• 第四篇：PaipopSDK 如何封装 LingXinSDK
• 第五篇：AI 播放时如何实现自然语音打断
• 第八篇：本地音量与云端动作指令
• 本文：一次从端到端等待追到音频历史状态的优化记录。

一、先把“打断慢”分成两个问题#

项目使用杰理 AC791N/WL82。玩具业务层负责状态机、统一麦克风、预录音和播放控制；自研 PaipopSDK 封装第三方 LingXinSDK，对接云端对话能力；本地端点检测使用仓库中已有的 WebRTC VAD 核心。

这里有两个容易混在一起的检测过程：

前者慢，表现为喊了几次玩具才停下来；后者慢，表现为玩具已经停止旧回答，自己也说完了，却还在等待。

本次重点处理的是后者。降低播放期的触发门限，可以让打断更容易发生，但不能直接保证打断后的录音更早结束。

按键打断也有同样的等待，是一条很重要的线索：按键不需要经过“是否有人抢话”的声学确认，如果它也慢，就不能只盯着语音打断灵敏度。

二、先建立分段时间线，而不是直接判断“云端慢”#

从用户说完到听到回复，中间至少经过：

1
实际最后一个字结束
2
    ↓
3
本地端点检测认定说完
4
    ↓
5
停止录音，排空已采集音频，发送 end_audio
6
    ↓
7
云端完成识别和回答处理，返回首段音频
8
    ↓
9
接收缓冲、解码、音量处理、DAC、扬声器出声

我在这些边界增加了分段日志，包括：

• pcm_sink_ready：新录音接收通道就绪。
• task_started：云端确认新任务启动。
• local_input_end：本地正式判停。
• upload_stop_begin、upload_sender_done：停止时剩余多少音频，什么时候排空。
• end_audio finish、asr_final、ai_text_first：结束指令、最终识别、首段回答文本。
• decoder_first_pcm、decoder_first_signal_pcm：首个解码 PCM 和首个达到诊断能量门限的 PCM。

打断场景还需要观察旧任务退役、新连接建立和新任务确认，但这些操作可能与用户说话并行，不能把所有阶段耗时不加区分地直接相加。

另一个容易误读的地方是时间戳的含义：

“VAD 最后一次判成语音的处理时间”不是“用户实际闭嘴的时间”；“首段 PCM 解码出来”也不是“扬声器实际出声”。

因此，日志用于定位软件中的等待区间，体感用于确认体验是否改善；如果要报告严格的停嘴到声学首声延迟，还需要同步音频测量。

三、前几轮尝试分别解决了什么#

这些尝试不是全部无效，而是逐步消除了不同位置的开销。不能因为最终问题还在，就否认前面测到过的真实阻塞；也不能因为一个指标变好了，就宣布整体问题已经解决。

网络缓冲这一轮还有一个值得记录的细节：修改配置必须对应最终真正链接的库。当时玩具使用的是 SFC 版本的 lwIP，另一个头文件中较大的缓冲宏，并不代表当前固件真的使用了那个值。我核对了链接目标和最终产物，再构建玩具专用归档，没有覆盖其他工程使用的原厂库。

快速交接也不是简单关闭 socket 就结束。旧连接的业务事件需要失效，但销毁回调仍要能够释放资源；新轮必须有自己的代际校验，避免旧文本、旧音频或旧错误进入新对话。

这些处理保留在最终版本中。不过，当上传队列已经为空、新任务也早已启动，剩余的五秒等待就必须继续往别处找。

四、真正改变排查方向的是“提交之后并没有更慢”#

在最终修改之前，我让普通和打断场景尽量使用同一句“你给我背一首诗吧”，得到下面一组记录：

其中个别句子带有“你来给我”或“好”等差异，不是严格实验室条件下的完全相同输入。

右边这一列非常关键：**一旦本地真正提交，打断后的后半程并没有额外多等几秒。**这些轮次停止录音时的上传队列也都是空的。

左边一列则包含了实际说话和开始说话前的等待，不能把差值全部当成尾静音。但是结合用户反馈，它明确提示：应该重点看录音提交之前发生了什么。

另一次按键打断的记录更直接：新任务在打断后约 360ms 已经确认，本地判停后仅约 18ms 就完成结束指令发送，随后约 1.80s 解码出首段有信号 PCM。旧任务交接不是这轮残余几秒等待的主要解释。

五、400 毫秒门限为什么还能拖很久#

输入期端点检测的核心逻辑可以简化为：

1
if (raw_vad == 1) {
2
    last_voice_ms = audio_ms;
3
    silence_ms = 0;
4
} else if (speech_seen) {
5
    silence_ms += 20;
6
    if (allow_end && silence_ms >= 400) {
7
        ended = 1;
8
    }
9
}

这里的 400ms，是连续被算法判断为非语音的时长，不是从人的物理停声时刻自动开始的倒计时。

如果背景音一直被判断为语音，或者中间偶尔冒出一个语音判断，silence_ms 就会被清零。

一轮按键打断后的日志中，音频平均幅度已经从 10053 降到几百甚至一百多，但仍持续出现：

1
时间/s     mean     raw_vad     silence_ms
2
115.339    10053        1            0
3
115.839      899        1            0
4
116.342      236        1            0
5
116.839      161        1            0
6
117.339      813        1            0
7
118.839      417        0          400

累计的 voiced_ms 也在相应区间持续增长，不只是抽样时恰好碰到了几个语音帧。等到算法最后一次判声之后，400ms 尾静音逻辑本身是正常工作的；问题在于“最后一次判声”被推迟了。

必须强调，mean 是 PCM 幅度指标，不是声压级；幅度低也不能单独证明没有轻声人声。这里的日志提供的是一个应当追查的模式，而不是直接证明“这些全是回声”。

此前已经处理过另一个拖尾问题：当前 vendored core 的原始结果中，1 表示本帧被分类为语音，>1 表示内部保持产生的拖尾。包装后的 fvad_process() 会把二者都压成 1。端点已改用原始结果，避免把内部保持再次计入有效语音或叠加在自己的 400ms 上。

所以，这一次看到的持续 raw_vad=1，不是那个已经排除的包装层拖尾问题。

六、普通和打断的关键差别：VAD 先听到了什么#

本地端点 VAD 每轮都会初始化。问题并不是“忘了初始化”，而是初始化以后，它先处理了哪一段音频。

1
VAD 初始化
2
    ↓
3
播放期间的 AEC/SRC 预录音，更新分类器统计
4
    ↓
5
新一轮原生录音，继续沿用同一套分类器统计
6
    ↓
7
根据这套连续状态判断句尾

七、自适应 VAD 为什么会受历史影响#

这个 VAD 不是简单判断“音量有没有超过固定值”。它会提取不同频带的特征，比较语音和噪声模型，并随输入更新部分统计量。

因此，同样一段尾部声音，前面输入历史不同，内部模型不同，分类结果就可能不同。经过降噪的历史输入与未经同样处理的新输入，在背景能量和频谱分布上可能存在变化。

本次排查形成的机制解释是：

打断前缀先影响了新建端点的自适应统计，再接入处理方式不同的新录音；这种历史状态可能使尾部背景声继续被判成语音，反复清零静音计时。

代码确认了“历史参与模型更新”和“采音处理方式切换”；日志确认了持续判声；最终隔离这些状态后，打断的体感等待恢复到接近普通对话。这些证据支持沿着历史状态处理问题。

不过，最终修改同时清理了分类器状态和 FIR 历史，还重启了尾静音计数，没有逐一拆开做消融实验，也没有同步录到所有实际尾音。因此，不应进一步断言某个具体频带、某个 GMM 参数或某一段扬声器回声就是唯一原因。

八、最终方案：保留内容，隔离模型#

最终版本的原则是：音频内容不能丢，但算法不必继承所有历史状态。

1
struct paipop_sink_call {
2
    paipop_voice_pcm_sink_t callback;
3
    void *user_data;
4
    u32 generation;
5
    u8 historical;
6
};

1
result = paipop_input_endpoint_process_gated(
2
    ep, pcm, samples, now_ms,
3
    !historical && allow_end
4
);

1
if (!ep->native_started && ep->history_audio_ms) {
2
    WebRtcVad_InitCore(ep->vad);
3
    WebRtcVad_set_mode_core(ep->vad, 1);
4

5
    memset(ep->history, 0, sizeof(ep->history));
6
    ep->write_pos = 0;
7
    ep->decimate_phase = 0;
8
    ep->last_raw_vad = 0;
9
    ep->silence_ms = 0;
10
}
11
ep->native_started = 1;

九、另外一项小调整：让语音打断更容易通过确认#

排查期间还抓到一次独立的触发问题：候选声音的强度、持续语音和其他条件都满足日志中的要求，但确认窗口里只有 15/24 个有效帧，占比取整后为 62%，低于原先 65% 的要求，因此被拒绝。约两秒后，下一次候选才确认成功。

针对这个现象，我把 active_pct 从 65 调到 60，保留绝对音量门限、降音复核、保持比例及其他防回声条件。通过已有调参接口应用、读回并保存，重启后也确认保留。

这两个改动解决的是不同阶段：

• 65%→60%：降低播放期打断确认的难度。
• 历史模型隔离：处理成功打断以后，新一轮录音迟迟不结束的问题。

降低占比可能增加误打断概率，因此没有顺带降低全部音量门限，也没有把触发条件改成“检测到一点声音就停播”。

十、验证不只看“结束得更快”#

这次修改最危险的回归不是仍然慢，而是看起来很快，实际上把句子截断了。因此主机测试与实机测试关注不同层次。

十一、需要继续保留的边界#

400ms 是产品交互取舍，不是通用最优值。长句中的自然停顿如果超过判停条件，仍可能被分成两轮；轻声尾字、远场说话、高播放音量和持续背景噪声都值得继续回归。

新段中出现语音后，静音计时必须仍然清零，不能为了让结果更快而忽略真实的续说。上传仍要发送已采到的完整音频，不能通过直接丢队列掩盖等待。

原始 PCM 导出是受信局域网内的开发诊断能力，会占用额外资源，连接导出时还会增加网络负载。正式版本应关闭这类测试接口，不应把它作为无认证的常驻对外能力发布。

另外，本次没有通过关闭 ASR 来优化。关闭识别文本上报不等于云端不再做语音理解，也不改变本地什么时候发送结束指令；在已经观察到“本地还没提交”的情况下，这不是解决当前差异的直接路径。

十二、源码与排障记录索引#

以下位置相对 AC79 SDK 根目录，描述的是 EP8 联调工作区，不代表第三方原始 SDK 默认就具备这些行为。

总结#

这次优化没有通过提前隐藏麦克风、删除尾部 PCM 或取消安全检查来制造“更快”的表现。我先沿着录音、上传、任务交接、云端返回和播放建立分段计时，处理掉真实存在的上传积压和旧任务等待，再用普通与打断的对照样本，把剩余问题缩小到本地提交之前。

最后的关键发现是：相同的 VAD 参数，不代表相同的输入历史，也不代表相同的实际判停时间。打断为了保住用户句首而引入了历史预录音，而端点又把这些经过不同前处理的音频连续用于更新同一套模型。

我在音频处理边界上清理分类器和滤波历史，保留短句、候选语音和无输入预算，并继续用实时队列边界限制提交。这样既没有牺牲上传内容，也避免了让历史模型状态一直影响新录音的收尾。经过主机回归、整机烧录和交替实测，两种入口的主观等待恢复到基本一致。

这次排障留下的一个重要经验是：实时音频系统中的延迟，不仅藏在函数执行、网络传输和队列长度里，也可能藏在跨阶段沿用的算法状态里。