更新 Pipecat 实时链路实验结论
This commit is contained in:
ylhan
@@ -6,8 +6,9 @@
|
||||
> `README.md`（代码说明）、`部署说明.md`（运维）——这两份也在代码仓库。
|
||||
>
|
||||
> 更新：2026-09-15。状态：**助手本体已在服务器上实现并跑通**（端到端测试 16/16）；
|
||||
> **Pipecat 传输层实验已做，传输层通、帧路由未通**（见 §10 与
|
||||
> `P0-Pipecat传输层实验报告.md`）——**A/B 架构方案待定**，这是当前卡点；
|
||||
> **Pipecat 实时语音链路已闭环**（见 §10 与
|
||||
> `P0-Pipecat传输层实验报告.md`）——A 方案已确定：Pipecat 管传输/帧/RTVI，
|
||||
> 自有引擎管会话语义；当前风险转为真实首音延迟与真人中文识别率；
|
||||
> 设备侧（N5095 外设桥、ESP32）尚未开始。
|
||||
> 已确认：Ubuntu 24.04；N5095 / 16G 作为**客户端**；助手本体部署在 cadadmin-server（i9-14900K / 3090）；麦克风、音箱、摄像头均未购；屏幕已于 09-14 到货并点亮（2.8 寸 ILI9341 触摸屏，非原定的 1.28 寸圆屏）。
|
||||
> 核心目标：听得清、回应及时、可打断、表情明确、转头自然。
|
||||
@@ -55,7 +56,7 @@
|
||||
│ 会话引擎（身份 → 记忆 → LLM → TTS） │
|
||||
│ ├─ LLM：DeepSeek deepseek-flash（云端，关思考） │
|
||||
│ ├─ TTS：Qwen3-TTS 1.7B（RTX 3090，独立 HTTP 服务 :18040） │
|
||||
│ ├─ 传输：Pipecat SmallWebRTC :7860（实验，帧路由未通） │
|
||||
│ ├─ 传输：Pipecat SmallWebRTC :7860（实时链路已闭环） │
|
||||
│ ├─ STT：Zipformer 中英宽带 int8（CPU 4 线程） │
|
||||
│ ├─ 记忆：SQLite（按 owner_user_id 强制隔离） │
|
||||
│ └─ 身份：手动切换 + 访客兜底 │
|
||||
@@ -406,41 +407,34 @@ P5通过Home Assistant统一调用。按实际设备比较官方Xiaomi Home和Xi
|
||||
### 下一步顺序（按风险从高到低）
|
||||
|
||||
评审建议的思路——**先把风险最大的实时语音链路闭环**——认可并采纳。
|
||||
但执行顺序要修正一处：**服务端目前没有任何客户端能连的入口**，
|
||||
所以第一块不是客户端，是服务端的 WebRTC 入口。
|
||||
|
||||
> 核实过：代码里 `pipecat` 一次都没被 import 过（只在 `requirements.txt` 里），
|
||||
> 引擎是独立 asyncio，由测试脚本用文件音频驱动。**没有进程在监听 WebRTC 连接。**
|
||||
服务端 WebRTC 入口和客户端骨架现已完成。2026-09-16 通过 SSH 隧道打开
|
||||
Pipecat Playground 做了真人浏览器对话，麦克风 → STT → LLM → TTS → 浏览器播放
|
||||
正常。当前仍是 P1 调试形态：连接后持续上传并响应有效语音；正式的本地唤醒、
|
||||
待机不上传和 20 秒连续对话窗口留在 P2，本轮按决定暂不实现。
|
||||
|
||||
| # | 步骤 | 状态 | 能验证什么 / 不能验证什么 |
|
||||
|---|---|---|---|
|
||||
| 0 | **音频边界定稿** | ✅ 2026-09-15 完成（见 §5） | 决定了客户端接口形态 |
|
||||
| 1 | **服务端 WebRTC 入口 + 客户端骨架** | 🔶 **传输层跑通，帧路由未通**（见 `P0-Pipecat传输层实验报告.md`） | 已验证：信令、ICE、data channel、双向媒体轨。**未验证：帧进不到自定义处理器，引擎从未运行** |
|
||||
| 1b | **查清帧路由根因 → 定 A/B 方案** | **待办，当前卡点** | 根因决定 A 方案（Pipecat 只做传输）是否可行，还是必须转 B（按框架 service 模型重构） |
|
||||
| 1 | **服务端 WebRTC 入口 + 客户端骨架** | ✅ **实时链路已闭环**（见 `P0-Pipecat传输层实验报告.md`） | 已验证：信令、ICE、data channel、帧路由、STT→LLM→TTS、文件与浏览器真人非静音回复 |
|
||||
| 1b | **查清帧路由根因 → 定 A/B 方案** | ✅ **根因已定位，采用 A 方案** | NLTK 运行时下载导致 setup timeout；不是模型不兼容。网页 RTVI 保留 |
|
||||
| 2 | **N5095 客户端骨架** | 🔶 雏形已有（`client/test_client.py`） | 非 trickle ICE、data channel 心跳、文件音频实时发送、回复录音都已实现。**不做 AEC/播客参考/打断**——那些要真实声卡 |
|
||||
| 3 | **接入真实麦克风与音箱** | 阻塞：硬件未购 | 唯一能验证 AEC、打断、唤醒的一步，也是 P2 的全部内容 |
|
||||
| 3 | **接入真实麦克风与音箱** | 阻塞：硬件未购；网页仅验证普通麦克风对话 | 唯一能完整验证阵列 AEC、打断、本地唤醒的一步，也是 P2 的全部内容 |
|
||||
| 4 | **STT 中文识别正确率** | 阻塞：需录音 | 见下"最大功能风险" |
|
||||
| 5 | ESP32 表情串口 | 硬件已到货，可独立推进 | 串口协议、表情渲染 |
|
||||
| 6 | 摄像头、多人跟踪、电机 | 阻塞：硬件未购 | — |
|
||||
|
||||
### 第 1 步的实验结论（2026-09-15）
|
||||
|
||||
**传输层可用，但"把整条会话逻辑塞进一个 FrameProcessor"不是开箱即用的。**
|
||||
**实时链路已闭环，A 方案成立。** 原 `process_frame` 为 0 的根因是 Pipecat
|
||||
setup 阶段预热 NLTK `punkt_tab`，首次下载阻塞后触发 20 秒 timeout；worker 尚未
|
||||
发送自动 StartFrame，并非 Pipeline 接线或自定义处理器模型不兼容。
|
||||
|
||||
自定义处理器被创建、`setup()` 被调用，但 **`process_frame` 调用次数为 0**——
|
||||
连自己注入的 StartFrame 都没进去。现象是"连接全对、音轨协商成功、
|
||||
但助手永远不说话，且日志里一条错误都没有"。
|
||||
修复后自动 StartFrame、250+ 个输入音频帧均正常经过 `EngineProcessor`，完整
|
||||
文件音频 → STT → DeepSeek → Qwen3-TTS → WebRTC 返回非静音语音。保留 RTVI
|
||||
和 `/client/` 网页入口，同时继续支持自写 aiortc/N5095 客户端。
|
||||
|
||||
**这对 A/B 决策的影响**：实验前判断"Pipecat 的价值收敛到传输层"，
|
||||
现在要修正——**传输层与自定义逻辑之间的接缝比预想的深**。
|
||||
B 方案恰恰绕开这个接缝（用框架原生 service，不由一个处理器吞掉全部）。
|
||||
|
||||
**但根因未定位**，两种可能必须区分：
|
||||
- 若是接线错误（管线用法与 Pipecat 1.10 的实际约定不符）→ 接缝浅，A 仍可行
|
||||
- 若是模型不兼容（该版本不接受这种用法）→ 接缝深，应转 B
|
||||
|
||||
实验同时挖出 **8 个 Pipecat 集成坑**（客户端需发 ping、offer 无媒体则不收集
|
||||
ICE 候选、`run()` 要 WorkerParams、后台异常被静默吞掉等），
|
||||
实验累计挖出 **13 个集成坑**（客户端需发 ping、offer 无媒体则不收集
|
||||
ICE 候选、Playground 需要 `/start`、`run()` 要 WorkerParams、后台异常被静默吞掉等），
|
||||
每个都表现为"什么都没发生"，详见实验报告。
|
||||
|
||||
**第 2 步的边界要说清楚**：用合成音频能验证传输层，**验不了 AEC 和远场识别**——
|
||||
|
||||
Reference in New Issue
Block a user