Rdzleo/Baji_Rtc_Toy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Baji_Rtc_Toy/.planning/STATE.md
Rdzleo 3dc6cadf49 diag(rtc-only): Phase 8 - 音频卡顿根因诊断埋点 + 数据采集报告 
数字人 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>
2026-05-15 11:40:42 +08:00

2.6 KiB
Raw Blame History

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 后如何接驳（需确认数字人模式是否需要触摸交互）