ylhan
bb4fa3028e
方案：定稿客户端/服务器音频边界，修正下一步顺序
音频边界（§5 新增章节，从"待定稿"改为"定稿"）
四个问题的决定：
- 传什么：闲置关闭，会话中持续上传（含 0.5–1s 预卷）
闲置时服务器完全听不到房间声音；会话中上传完整音频流，
服务端才能做可靠的"说完判定"。唤醒控制的是"是否上传"，
不是"是否处理"。
- 唤醒：本地。延迟低、断网可响应；它是注意力的门，不是传输的门。
- 打断：客户端判定。三条理由——WebRTC 的 AEC 本来就在客户端跑
（需要播放参考），客户端麦克风信号已是去回声的；客户端知道自己
正在播什么，"用户在此刻开口"本地可判，不需额外协议；比服务端
判定少一个来回，更容易满足 ≤300ms。
- 断线：WebRTC 内建 ICE restart；抖动缓冲 100–200ms 待实测。
缓冲换稳定性但直接加首音延迟，不能凭感觉设。
同时写明接口约定（上下行各传什么）、三条约束（播放参考须本地可得、
预卷缓冲、上传不等于存储）和这条边界的已知代价。
修正下一步顺序
原顺序把"N5095 WebRTC 客户端"列为第一步，但核实后发现：
代码里 pipecat 一次都没被 import 过（只在 requirements.txt 里），
引擎是独立 asyncio 由测试脚本驱动，**服务端没有任何客户端能连的入口**。
所以第一块是服务端 WebRTC 入口，客户端排第二。
新顺序列出六步并标注每步的状态与阻塞条件，明确说明：
第 2 步用合成音频只能验证传输层，**验不了 AEC 与远场识别**——
那要等真实硬件。
2026-09-15 13:05:35 +08:00
..
2026-09-15 13:05:35 +08:00
2026-09-14 17:02:12 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00