Rdzleo
3dc6cadf49
数字人 RTC 模式音频卡顿根因定位。通过 4 类 ESP_LOGW 埋点采集运行时 数据，对照表格判定根因，输出 Phase 9 实施分支决策。 埋点实现（main/application.cc，PHASE8_DIAG_ENABLE 宏开关，关闭后零开销）： - DIAG-1 queue 深度：3 处（出队 + WebSocket 入队 + RTC 入队），50ms 节流 - DIAG-2 codec->OutputData 写入耗时：>15ms 阈值告警 - DIAG-3 WiFi RSSI：OnClockTimer 1Hz - DIAG-4 heap 快照 + 碎片率：OnClockTimer 1Hz 实测结论（见 DIAG_REPORT.md）：用户感知卡顿 = 两个独立根因 - A. 开机播报阶段 ③' codec init 时序缺陷（ES7210 I2C 失败 + 126 次 write_slow 集中在 2-13s） - B. RTC 对话阶段 ⑤ Opus/WebSocket 应用层帧到达抖动 （queue 突发堆积 19 + queue=0 出现 58 次，但 codec 写入 0 次 slow） 完全排除：① CPU 争抢、② PSRAM 带宽、④ WiFi 丢包（RSSI -24~-33dBm 极强）、⑥ 内存碎片（heap 全程稳定） Phase 9 推荐分支 B'（双线修复，原 A/C 的 EAF 方案不适用）： - 9.1 应用层 jitter buffer（fill-threshold + drain）—— 解 B - 9.2 开机 codec init 时序修复（ES7210 reset + ready 等待）—— 解 A - 估时 1 天 ROADMAP 同步：Phase 7 矫正为 battery_psm（实际状态）、Phase 8 新增 诊断、Phase 9 占位待 Phase 8 决策、原"集成测试"挪到 Phase 10。 新增 .planning/STATE.md 记录 roadmap evolution。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
43 lines
2.6 KiB
Markdown
43 lines
2.6 KiB
Markdown
# STATE — 项目状态追踪
|
||
|
||
> 跨 session 的项目状态、roadmap 演化、关键决策记录。本文件用于让新 session 快速恢复项目上下文。
|
||
|
||
## Current Milestone
|
||
|
||
- **Milestone**: `digital_human_rtc` (数字人 RTC 项目)
|
||
- **Branch**: `Rtc_AIavatar`
|
||
- **ROADMAP**: `.planning/milestones/digital_human_rtc/ROADMAP.md`
|
||
- **总阶段数**: 10
|
||
- **当前进度**: Phase 1-6 完成，Phase 7 (battery_psm) 进行中
|
||
|
||
## Accumulated Context
|
||
|
||
### Roadmap Evolution
|
||
|
||
记录 roadmap 在项目过程中的演化（按时间倒序，最新在前）：
|
||
|
||
- **2026-05-15** — Phase 7 ROADMAP 同步矫正：原 Phase 7 "集成测试 + 推送" 因发现文件系统已有 `phase_07_battery_psm`（电量保护重构）而被重编号为 Phase 10。Phase 7 在 ROADMAP 中改写为指向 `phase_07_battery_psm/README.md`。
|
||
- **2026-05-15** — Phase 8 added: 数字人 RTC 音频卡顿根因诊断。通过 4 类 ESP_LOGW 埋点（audio queue 深度 / PCM write 耗时 / WiFi RSSI / heap）定位卡顿真因（CPU/PSRAM/DMA/WiFi/Opus/碎片 6 选 1+ 组合），产出 DIAG_REPORT.md 决定 Phase 9 实施策略。
|
||
- **2026-05-15** — Phase 9 added (占位): 音频卡顿实施优化。具体方案待 Phase 8 数据决策，分支预案 A=EAF 旁路 / B=WiFi 扩容 / C=完整切 EAF+资源再分配 / D=DMA 排查 已列入 ROADMAP。
|
||
|
||
### Key Technical Decisions
|
||
|
||
- **方案 A vs 方案 B 路线分歧已用 Phase 8 数据驱动决策化解**：
|
||
- 方案 A = `eaf_dec_*` 旁路替换 lv_gif（保留 LVGL）
|
||
- 方案 B = 数字人模式完整切 esp_emote_gfx（弃用 LVGL）
|
||
- 两者选择不靠拍脑袋，靠 Phase 8 诊断报告
|
||
- **EAF 集成边界确认**：
|
||
- 数字人模式 LVGL 实际范围只有 `main/dzbj/ai_chat_ui.c` (458 行) + `main/display/lcd_display.cc` 数字人分支 (~300 行)
|
||
- 不涉及任何 `ui/screens/` 下 SquareLine 界面（属吧唧模式，`CONFIG_BAJI_BADGE_MODE` 编译排除）
|
||
- `ui_ScreenUpdate` 已确认是吧唧模式 BLE 收图 UI，**非 OTA**，不影响数字人模式
|
||
- **方案 B 完整切若启用，资源账本**：
|
||
- 释放：~40KB DRAM + ~80KB PSRAM（LVGL 框架本体）
|
||
- 投入：WiFi RX 缓冲扩容 ~15KB DRAM + Opus jitter buffer ~10KB PSRAM + RTC SDK jitter ~40KB PSRAM
|
||
- 净结余：~20KB DRAM + ~10KB PSRAM 仍可备用
|
||
|
||
### Open Risks (Phase 9 实施时验证)
|
||
|
||
- `gfx_label` 是否支持中文自动换行 + 双行居中（方案 B/C 阻塞点）
|
||
- `font_puhui_20_4.c`（8.5MB LVGL bitmap font）能否被 EAF 直接复用
|
||
- `cst816s` 触摸路径在弃用 LVGL 后如何接驳（需确认数字人模式是否需要触摸交互）
|