阅读导航#

1. 杰理 AC79 应用启动与注册机制详解：从 REGISTER_APPLICATION 到 start_app
2. paipopAi 对话玩具解析（一）：从 APP_STA_START 到眼睛任务与摇一摇服务
3. paipopAi 对话玩具解析（二）：从按键与摇一摇到对话打断
4. paipopAi 对话玩具解析（三）：从按键启动到云端语音回答
5. paipopAi 对话玩具解析（四）：PaipopSDK 如何封装 LingXinSDK
6. 本文：从 AEC、VAD、预录 PCM 和轮次隔离理解自然语音打断。
7. paipopAi 对话玩具解析（六）：从开机联网到 AP 网页配网

本文范围与证据边界#

本文基于独立正式发布仓库 Paipop_YP_Toy_release_v128 的 main@24a83f9，版本为 V1.2.8 / 10208，目标平台为杰理 AC791N/WL82。

本次采用静态源码复核，没有重新烧录设备或采集新的串口日志。因此：

代码归属也需要分清：

一、这不是简单地“检测到声音就打断”#

最直观的方案可能是：

1
麦克风检测到声音
2
→ 停止 AI 播放
3
→ 开始下一轮录音

但在真实设备上，这种方案几乎一定会误触发。

因为 AI 播放时，扬声器声音也会进入麦克风：

1
AI 回答音频
2
    ↓
3
扬声器发声
4
    ↓
5
空气与机壳传播
6
    ↓
7
麦克风重新采集
8
    ↓
9
普通 VAD 认为“有人说话”

除此之外，麦克风还可能采到：

• 房间里的电视或其他人声；
• 玩具移动、敲击和摩擦产生的机械声；
• ADC 和模拟前端底噪；
• DAC 启动、功放开关产生的瞬态；
• 播放停止以后尚未衰减的回声尾；
• AEC 尚未完成收敛时残留的扬声器声音。

所以自然打断实际包含三个独立问题：

1
能不能检测到用户开口
2
        +
3
能不能排除设备自己的声音
4
        +
5
能不能保住检测前的用户语音

对应到项目：

因此，AUDIO_SERVER_EVENT_SPEAK_START 只是一个候选信号，不是最终打断命令。

二、FLOW-05-01：一次播放期自然打断的完整链路#

1
云端 MP3 到达
2
  → paipop_cloud_audio_play_feed()
3
  → 解码器启动并确认 AUDIO_DEC_START
4
  → cloud_audio_notify_playback_started()
5
  → paipop_fsm_playback_started_sync()
6
  → VAD 模式切换为 SPEAKING
7
  → paipop_voice_activity_notify_playback_started()
8
  → 等待 AEC 预热 450 ms
9

10
用户开始说话
11
  → audio_server 发出 AUDIO_SERVER_EVENT_SPEAK_START
12
  → 自适应能量门限初筛
13
  → 锁定最近 1 秒预录 PCM
14
  → paipop_cloud_audio_play_duck(20)
15
  → 继续测量约 300 ms
16
  → 检查语音连续性、有效帧比例和降音后能量
17

18
确认近端人声
19
  → paipop_events_post(PAIPOP_EVT_VOICE_INTERRUPT, SPEAKING)
20
  ⇢ 通过 sys_event 队列切到 app_core
21
  → paipop_fsm_dispatch()
22
  → 校验当前 VAD 模式与对话状态
23
  → paipop_engine_interrupt_chat()
24
  → Paipop_StartNewChat()，沿用 conversationId
25
  → 新录音 sink 打开并获得新 generation
26
  → 先排空 pending 中的预录 PCM
27
  → 再转发实时 24 kHz PCM

其中 ⇢ 是一次异步队列跳转，不是普通同步函数调用。VAD 服务负责“提出经过验证的候选”，FSM 才负责“当前业务是否接受这个候选”。

关键调用边证据：

三、VAD 服务有三种工作模式#

公共头文件定义：

1
enum paipop_voice_activity_mode {
2
    PAIPOP_VOICE_ACTIVITY_DISABLED = 0,
3
    PAIPOP_VOICE_ACTIVITY_THINKING,
4
    PAIPOP_VOICE_ACTIVITY_SPEAKING,
5
};

它不是玩具主 FSM，而是麦克风检测服务的局部状态。

1
VAD detection disabled
2
≠
3
microphone capture must stop

1
硬件 VAD 持续命中
2
+ 动态能量门限通过
3
+ 不在播放回声尾保护期
4
→ 接受为思考期打断

1
AEC/NLP/ANS 可用
2
+ DAC 播放已真实开始
3
+ AEC 预热完成
4
+ 硬件 VAD 命中
5
+ 自适应能量门限通过
6
+ 降音后的语音仍连续、仍有足够能量
7
+ 当前播放器 generation 仍可打断

四、为什么整个系统只能有一个麦克风采集所有者#

旧式录音实现通常是每个功能自己打开 ADC：

1
云端录音器 → 打开一次 audio_server enc
2
本地 VAD   → 再打开一次 audio_server enc

但两个模块争用同一个 ADC、AEC 和编码服务，可能造成：

• 第二次打开返回忙或平台错误；
• 停止其中一个录音器时误伤另一个；
• AEC 参考和 PCM 回调属于不同实例；
• 生命周期竞态导致旧回调落进新对象。

正式版采用相反结构：

1
                 ┌─ 本地 VAD / AEC 检测
2
唯一 audio_server enc ─┤
3
                 └─ 24 kHz PCM sink → LingXin 录音器

paipop_voice_activity.c 是唯一采集所有者。LingXin 需要录音时，paipop_audio_recorder.c 不再默认打开第二个 ADC，而是优先注册：

1
paipop_voice_activity_sink_open(
2
    recorder_shared_sink_write,
3
    recorder_handler,
4
    recorder_handler->frame_size,
5
    &recorder_handler->shared_sink_generation);

recorder_shared_sink_write() 再把统一采集得到的 PCM 交给 LingXin 的 data_callback。

三个细节很重要。

1
24000 Hz
2
单声道
3
S16 PCM
4
960 字节/帧

1
24000 samples/s × 2 bytes × 20 ms = 960 bytes

五、为什么本地检测和云端 ASR 使用两套采集配置#

统一所有权不等于永远使用同一种采样配置。源码定义了两个 profile：

1
PAIPOP_CAPTURE_PROFILE_VAD_AEC_16K
2
PAIPOP_CAPTURE_PROFILE_ASR_NATIVE_24K

选择规则非常直接：

1
if (sink_active) {
2
    return ASR_NATIVE_24K;
3
}
4
return VAD_AEC_16K;

1
AI 播放/思考期：优先抗回声检测 → 16 kHz AEC
2
云端正式收音期：优先识别清晰度 → 原生 24 kHz

六、16 kHz 预录 PCM 怎样交给 24 kHz 云端#

打断发生时，用户开头的部分语音是在 VAD_AEC_16K profile 下采到的。如果直接丢掉，就会出现：

1
用户说：“不是，我问明天”
2
云端收到：“我问明天”

因此检测期 PCM 会通过一个固定比例的线性 SRC 从 16 kHz 转成 24 kHz。

比例是：

1
24000 / 16000 = 3 / 2

源码不是按每个块孤立插值，而是保存：

• 上一个输入样本 src_prev；
• 当前三分之一相位 src_phase_thirds；
• 尚未填满的上传帧 upload_frame。

这样跨越 10 ms 输入块时不会在块边界突然跳变。每积累到 960 字节，就形成一帧与云端录音器格式一致的 20 ms PCM。

需要诚实说明：线性 SRC 的计算量低、适合 MCU，但滤波质量不如带抗混叠滤波器的专业重采样器。这里它只承担短暂预录片段的格式衔接；正式云端录音会切换回原生 24 kHz。

七、为什么不能在 OUTPUTING 阶段立即启用播放期打断#

LingXinSDK 的 OUTPUTING 只表示云端进入输出阶段，并不等于扬声器已经发声：

1
OUTPUTING
2
→ 第一批 MP3 到达
3
→ 建立解码器
4
→ 首播缓存
5
→ AUDIO_DEC_START
6
→ DAC 真正输出
7
→ PLAYBACK_STARTED

如果一收到 OUTPUTING 就启用 SPEAKING 检测：

• AEC 还没有稳定的播放参考；
• 解码启动瞬态可能被当成人声；
• 本地提示音或上一轮尾音可能被归到当前流。

所以 FSM 在 OUTPUTING 到来而 playback_active == 0 时主动关闭检测。播放器只有在 AUDIO_DEC_START 成功且当前 stream_generation 仍有效时，才设置 playback_started_notified。

随后调用顺序是刻意设计的：

1
paipop_fsm_playback_started_sync()
2
→ FSM 先选择 SPEAKING 模式
3

4
paipop_voice_activity_notify_playback_started()
5
→ VAD 再记录物理播放时刻并启动预热

这可以保证 VAD 收到“播放开始”时，业务模式已经同步切换完成。

面试时可以总结为：

协议状态不能代替硬件事实。OUTPUTING 是云端状态，PLAYBACK_STARTED 才是 DAC 生命周期事实。

八、AEC 为什么还需要 450 ms 预热#

即使 AEC 已经打开，也不能在第一个播放样本出现时立刻相信输出。

AEC 需要根据扬声器参考信号估计声学回声路径，包括：

• DAC 到功放的延迟；
• 扬声器到麦克风的空气传播；
• 机壳反射和共振；
• 当前音量对应的回声幅度。

正式版默认：

1
warmup_ms = 450;

真实播放开始后，系统先记录：

1
playback_started = 1
2
warmup_done = 0
3
barge_in_armed = 0

450 ms 计时到期且以下条件仍成立时，才设置：

1
capture_open
2
+ aec_ready
3
+ desired_mode == SPEAKING
4
+ playback_started
5
→ barge_in_armed = 1

计时器参数携带 playback_generation。如果期间切换了播放流、模式或录音器，旧计时器即使晚到也会因 generation 不匹配而退出。

这个预热窗口会牺牲回答开头几百毫秒的可打断性，但能显著降低播放启动阶段的自打断风险。

九、第一层筛选：硬件 VAD 不是最终裁判#

VAD_AEC_16K profile 会配置：

1
req.enc.use_vad = 2;
2
req.enc.vad_auto_refresh = 1;
3
req.enc.vad_start_threshold = speech_ms;
4
req.enc.vad_stop_threshold = 0;

默认 speech_ms = 350，表示音频服务需要观察到一段持续活动，才产生 AUDIO_SERVER_EVENT_SPEAK_START。

持续时间可以过滤一部分极短撞击声，但不能区分：

• 用户说话；
• 电视里的人声；
• AEC 残余回声；
• 持续机械噪声。

因此硬件 VAD 只负责降低软件处理频率和给出候选事件，后面还要检查后 AEC PCM 的实际能量。

十、第二层筛选：动态噪声门限#

系统对每个 16 kHz PCM 帧计算平均绝对值：

1
frame_level = Σ abs(sample[i]) / samples

它比峰值更不容易被单个脉冲样本影响，计算量也适合 MCU。

1
检测模式已启用
2
+ 当前不是语音段
3
+ 没有确认任务
4
+ 没有 pending 预录
5
+ 尚未锁存打断

1
dynamic_gate = max(
2
    noise_floor × noise_pct / 100,
3
    noise_floor + headroom,
4
    startup_gate
5
)

1
noise_pct   = 260%
2
headroom    = 32
3
startup_gate = 96

十一、思考期打断和播放期打断为什么不同#

1
锁存 hit
2
→ 锁定预录 PCM
3
→ 发布 VOICE_INTERRUPT(THINKING)

1
锁定预录
2
→ 将 AI 音量临时降到 20%
3
→ 继续观察 300 ms
4
→ 判断声音是否仍持续

十二、FUNC-05-01：播放期降音复核怎样工作#

入口位于 paipop_capture_encoder_event() 对 AUDIO_SERVER_EVENT_SPEAK_START 的处理。

候选建立前要满足：

1
capture_open
2
+ aec_ready
3
+ desired_mode == SPEAKING
4
+ playback_started
5
+ warmup_done
6
+ barge_in_armed
7
+ !cooldown_active
8
+ !confirm_pending
9
+ !hit_latched
10
+ !pending_active

建立候选时会快照：

• 候选前 PCM 平均能量；
• 当前动态门限；
• 播放已经持续的时间；
• 当前绝对门限；
• 有效帧比例和保持比例要求；
• 确认窗口长度；
• 临时降音比例。

然后锁定 1 秒预录，并调用：

1
paipop_cloud_audio_play_duck(duck_pct);

默认把当前数字音量降到原音量的 20%，而不是立即暂停或销毁播放器。这是一个可逆操作：如果候选是假信号，可以继续播放未完成的回答。

1
post_level_sum
2
post_level_frames
3
active_level_sum
4
active_frames
5
speech_continuous

1
候选开始时的动态门限
2
候选前能量 × retain_pct
3
绝对确认门限

1
扬声器降音
2
→ 麦克风回声同步下降
3
→ retain_percent 或 active_percent 不达标
4
→ 判定 echo/noise

1
扬声器降音
2
→ 用户仍继续说话
3
→ 后 AEC 能量保持
4
→ 判定 near-end

十三、误触发时为什么不能直接丢掉旧回答#

如果确认条件不成立，系统执行：

1
恢复原始数字音量
2
→ 取消候选预录
3
→ 进入 700 ms 冷却期
4
→ 旧回答继续播放

这条回滚路径是自然体验的关键。否则每次玩具碰撞或电视声命中 VAD，AI 回答都会被永久截断。

冷却期内 barge_in_armed = 0。计时结束后，只有当前仍然是：

1
SPEAKING
2
+ playback_started
3
+ warmup_done
4
+ AEC ready
5
+ 没有其他候选

才重新允许打断。

同样，冷却计时器使用自己的 cooldown_generation。模式已经变化时，旧冷却回调不能重新打开检测。

十四、播放停止以后为什么还要保护 600 ms#

DAC 停止并不意味着麦克风中的回声瞬间归零。房间混响、机壳共振和 AEC 滤波器状态可能留下短暂尾音。

播放器停止时，VAD 从 SPEAKING 过渡到 THINKING。如果立即按思考期宽松规则接受声音，最后一小段 AI 尾音可能触发新一轮。

所以项目启动默认 600 ms 的 echo-tail guard：

1
播放停止
2
→ 进入尾音保护期
3
→ 若出现候选，立即开始保存 PCM
4
→ 不马上发布事件
5
→ 保护期结束时再次检查语音是否仍持续

如果语音持续到保护期结束，说明它更可能是用户真的在说话，于是接受已经缓存的候选；如果语音停止，则取消预录。

注意这里是“先保存、后确认”。如果等 600 ms 以后才开始录，真实用户的句首会全部丢失。

十五、FUNC-05-02：1 秒预录环形缓冲区#

统一采集服务始终将生成的 24 kHz、20 ms PCM 帧写入 preroll_buf。

容量计算为：

1
24000 samples/s × 2 bytes × 1000 ms = 48000 bytes

它是一个覆盖式环形缓冲：

1
新帧持续写入
2
→ 写到末尾后绕回开头
3
→ 永远保留最近约 1 秒

平时这里只保存历史，不上传给下一轮。当候选成立时，paipop_preroll_arm_window_locked() 会：

1. 清空本次 pending 队列；
2. 标记 pending_active = 1；
3. 记录当前旧 sink generation；
4. 找到环形缓冲中所需窗口的最老位置；
5. 按时间顺序复制到 pending 队列；
6. 后续实时 PCM 也继续追加到 pending。

自然语音和摇一摇使用 1000 ms；物理按键使用较短的 450 ms。按键事件通常比用户真正开口更早到达，较短窗口可以减少无意义静音和上传尾部积压。

1
候选前的历史
2
+ 确认窗口中的语音
3
+ FSM 与 SDK 交接期间的语音

十六、pending 队列怎样跨越新旧录音器#

pending 默认目标容量是 4 秒：

1
960 bytes/frame × 200 frames = 192000 bytes

如果堆内存不足，初始化会依次尝试：

1
4 秒 → 3 秒 → 2 秒 → 1 秒

至少保留一秒的退化策略比“一次分配失败就完全禁用服务”更适合嵌入式设备。

1
pending_after_sink_generation = current_sink_generation;

1
pending 中还有完整帧？
2
    ├─ 是：按时间顺序发送 pending
3
    └─ 否：清除 pending_active，转入实时发送

1
句首 → 确认期 → 交接期 → 当前实时语音

十七、为什么 VFS 回调里只入队，不做复杂处理#

杰理 audio_server 通过 VFS 风格的 fwrite 回调交付 PCM。该回调只负责把原始数据写入 raw_cbuf 并唤醒 paipop_pcm worker。

SRC、能量计算、预录路由和 LingXin 数据回调都在 worker 中执行。

这样做有三个理由：

• 音频服务回调必须快速返回，避免阻塞底层采集；
• LingXin 数据回调的耗时不应直接占用音频服务上下文；
• sink 打开、关闭和旧回调退出需要明确同步点。

这也是为什么代码专门维护 sink_inflight 和 sink_idle_sem：关闭 sink 时要等待已经发出的旧回调返回，防止 user_data 被释放后仍被访问。

十八、generation 不是一个计数器，而是一组生命周期令牌#

该模块包含多种 generation：

它们解决的是同一类问题：

1
旧异步操作晚到
2
→ 先比较它携带的 generation
3
→ 不属于当前生命周期
4
→ 直接忽略

为什么不能只用一个全局 generation？

因为这些子生命周期并不总是一起变化。例如一次误触发只需要废弃确认计时器，不应该同时让当前播放器和麦克风 sink 失效。分开的 generation 可以更精确地取消旧工作。

计数自增后如果回绕到 0，代码会再自增一次，因为 0 被保留为“没有活动实例”。

十九、为什么还要 mutex、generation 和 inflight 三层保护#

它们解决不同问题：

1
mutex
2
→ 防止多个线程同时读写复合状态
3

4
generation
5
→ 判断异步回调属于旧实例还是当前实例
6

7
inflight + semaphore
8
→ 等待已经进入回调的旧执行路径真正返回

只用 mutex 不够：回调可能已经复制出函数指针和 user_data，释放锁后才执行。

只用 generation 也不够：它能让回调拒绝新数据，却不能保证旧回调不再访问即将释放的对象。

因此 sink 关闭流程会：

1. 在锁内撤销 sink_active 和回调指针；
2. 释放锁；
3. 等待对应 generation 的 inflight 回调归零；
4. 最后允许上层销毁录音器对象。

锁顺序固定为：

1
sink_mutex → voice mutex

统一锁顺序用于避免 ABBA 死锁。

二十、VOICE_INTERRUPT 为什么还要经过 FSM 校验#

VAD 确认和事件被 app_core 消费之间存在时间差。这段时间里可能发生：

• 用户按键已经发起另一种打断；
• 网络断开；
• 播放自然结束；
• FSM 离开 ENGINE_CHAT；
• VAD 模式从 SPEAKING 切到 THINKING；
• 当前候选属于旧模式。

所以事件携带检测时的模式：

1
PAIPOP_EVT_VOICE_INTERRUPT,
2
PAIPOP_VOICE_ACTIVITY_SPEAKING

FSM 只在以下条件同时满足时接受：

1
detected_mode != DISABLED
2
+ fsm.voice_interrupt_mode == detected_mode
3
+ !exit_request_pending
4
+ !shake_interrupt_pending
5
+ state == ENGINE_CHAT

不满足时，FSM 不启动新轮，并立即取消 VAD 已经锁定的预录。

这是典型的“生产者初筛、状态机最终仲裁”：VAD 不直接控制对话引擎，避免音频线程绕过业务状态。

二十一、FUNC-05-03：确认以后怎样开启下一轮#

FSM 接受 VOICE_INTERRUPT 后会：

1. 保存旧轮是否已经输出，以及原 VAD 模式；
2. 关闭当前 VAD 模式；
3. 标记 exit_request_pending；
4. 打开 interrupt_phase_gate；
5. 保留 interrupt_preroll_ready；
6. 清除 30 秒无输入窗口；
7. 将眼睛切换为倾听；
8. 调用 paipop_engine_interrupt_chat()。

paipop_engine_interrupt_chat() 没有先在产品层同步等待 Paipop_ExitChat()，而是直接构造新的连续 CLOUD_VAD 轮次：

1
return paipop_engine_start_managed_round(
2
    0,      /* 不创建新 conversation */
3
    1,      /* 关闭 welcome audio */
4
    PAIPOP_CHAT_MODE_CLOUD_VAD,
5
    0,      /* 保持连续对话 */
6
    reason);

因此：

• conversationId 保持不变，保留上下文；
• 新一轮 turnId 会重新生成；
• 不播放欢迎音；
• 新录音器打开后直接接管 pending PCM。

底层 LingXinSDK 如何在内部协调旧 task 与新 task 属于第三方实现边界；产品源码能直接证明的是：产品通过 Paipop_StartNewChat() 请求同一 conversation 的新轮，并为异步交接准备了旧事件隔离与超时恢复。

二十二、新 STARTING 为什么可能比旧 EXIT 更早#

异步系统中不存在“源码调用顺序等于回调到达顺序”。打断后可能出现：

1
新轮 STARTING
2
→ 新轮 INPUTING
3
→ 旧轮 EXIT

也可能是：

1
旧轮 EXIT
2
→ 新轮 STARTING
3
→ 新轮 INPUTING

如果 FSM 把第一个 EXIT 无条件当成当前轮结束，就可能刚建立新录音器又退回空闲。

1
THINKING
2
OUTPUTING

二十三、播放器自身也要隔离旧流#

开始新轮时，旧 MP3 包和解码器事件也可能晚到。播放器通过 stream_generation、decoder_generation 和终止所有者处理：

• 新流初始化时生成非零 generation；
• feed、解码启动和 decoder event 都检查 generation；
• 硬停止时先关闭 accepting_feed；
• 后续迟到 feed 只记录一次并丢弃；
• PLAY_END 和 STOP_END 竞争时只允许一个终止所有者生效；
• 播放停止通知只发送一次。

这保证旧回答的 MP3 不会写进新回答的环形缓冲，也避免自然播放结束与主动打断同时拆除同一个解码器。

二十四、打断失败时怎样恢复#

自然打断不是不可逆事务。以下步骤都可能失败：

• 业务事件投递失败；
• 新轮请求返回 busy；
• sink 打开失败；
• 播放恰好自然结束；
• 退出回调迟迟不到；
• audio_server 暂时不可用。

1
强制快速退出旧会话
2
→ 标记继续同一 conversation
3
→ 再等待 4000 ms 恢复窗口

二十五、参数不是越灵敏越好#

正式版平衡默认值包括：

1
真阳性：用户抢话且成功打断
2
假阳性：无人说话却打断
3
假阴性：用户说话但没打断
4
交接延迟：开口到新 sink ready
5
语句完整性：ASR 是否丢句首/句尾

二十六、USB CDC 调参为什么默认只改 RAM#

项目支持通过 USB CDC 输入：

1
tune show
2
tune stats
3
tune preset sensitive|balanced|stable
4
tune set <name> <value>
5
tune save
6
tune reset

tune set 和 preset 默认只修改 RAM。只有显式执行 tune save 才写入 VM 区。

这样设计有两个理由：

• 实验错误不会因为重启而永久保留；
• 高频调参不会反复擦写 Flash。

保存记录包含：

1
magic
2
schema
3
length
4
values
5
CRC32

启动时只有字段全部匹配、CRC 正确且参数范围合法，才恢复保存值；否则回退到平衡默认值。代码还兼容 schema 1，并为新增门限补默认值。

这是一套很典型的嵌入式持久化配置设计：版本化、完整性校验、范围校验和安全默认值缺一不可。

二十七、这套设计最值得面试讲的五点#

二十八、几个容易被追问的问题#

二十九、怎样用一分钟讲清楚#

这个项目的自然语音打断不是检测到声音就停播。我设计了一个统一麦克风服务，避免本地 VAD 和 LingXin 云端录音同时争用 ADC。AI 思考或播放时，服务使用 16 kHz AEC/NLP/ANS profile 做本地检测；新一轮云端录音 sink 打开后切换到原生 24 kHz，保证 ASR 质量。播放真正进入 DAC 后先等待 450 ms AEC 预热，硬件 VAD 命中还要经过动态噪声门限；播放期候选会把回答降到 20%，继续观察 300 ms，只有降音后语音能量和连续性仍满足条件才确认是近端用户。检测期间最近一秒 PCM 和交接期间的新 PCM 都写入 pending 队列，新 sink 获得不同 generation 后先排空历史再发送实时音频。FSM 最终仲裁打断，并用 phase gate、迟到 EXIT 预算和看门狗隔离新旧轮回调。假触发或新轮启动失败时会恢复旧回答和检测状态。

三十、源码证据索引#

总结#

Paipop 的自然语音打断可以拆成四层：

1
声学检测层
2
硬件 VAD + AEC/NLP/ANS + 动态门限 + 降音复核
3

4
音频保存层
5
1 秒滚动预录 + 最长 4 秒 pending + 16k→24k SRC
6

7
异步安全层
8
mutex + inflight + 多类 generation + 超时回收
9

10
业务交接层
11
VOICE_INTERRUPT 事件 + FSM 仲裁 + phase gate + 同会话新轮

最值得记住的是：检测到用户只是开始，真正困难的是在设备自己发声的同时可靠地区分近端语音，并在数百毫秒确认和异步换轮期间不丢掉用户已经说出的内容。

这套方案没有把 AEC 或 VAD 神化成单点答案，而是把多个不完美信号组合起来：硬件 VAD 提供候选，动态门限适应环境，降音复核排除回声，预录队列保护句首，generation 和 FSM 处理乱序生命周期。对于资源有限的单麦克风嵌入式玩具，这是一种可落地、可调试、也能在面试中讲清设计取舍的完整工程方案。