32 lines
2.5 KiB
Markdown
32 lines
2.5 KiB
Markdown
|
# COM6 麦克风上传丢字排查
|
|||
|
|
|
|||
|
|
## 复现与定位
|
|||
|
|
|
|||
|
|
用户测试原话：“没有什么事儿，我今天带孩子出去旅游了”。
|
|||
|
|
2026-09-26 20:32（北京时间）的云端会话只留下“了”和“没有什么，我今天。”，助手随后针对残句回答。因此不是聊天记录页面单独漏显示。
|
|||
|
|
|
|||
|
|
随后设备观察窗口中，上行每约 2 秒送出 34–35 个 60 ms PCM 帧，发送返回错误为 0；这只能证明采集回调持续和 SDK 接口未报错，不能证明远端收到了完整声音。采集前两路麦克风都有信号。现有云端 S2S `asr.extra.end_smooth_window_ms` 为 1200，打断开启。本次不修改断句参数。
|
|||
|
|
|
|||
|
|
发现 RTC 外部 Opus 发送配置仍为 `s_sample_rate=16000`、`s_samples_per_frame=320`。接收端已在此前修复为 48000/960。实际编码器输入为 16 kHz 单声道 PCM，每包 20 ms；Opus RTP 的时钟应为 48 kHz，每包 960 ticks，而不是 PCM 样本数 320。
|
|||
|
|
|
|||
|
|
本地 SDK 符号/反汇编显示 `createLiteRtpTransceiver` 将 `globalGetAudioSampleRateSent` 结果传给音频发送流配置，因此该配置也用于传输层，不能仅按 PCM 输入频率设置。依据：[RFC 7587 §4.1](https://datatracker.ietf.org/doc/html/rfc7587#section-4.1)。实际丢字是否由此导致仍需修正后的真人对话确认。
|
|||
|
|
|
|||
|
|
## 修改
|
|||
|
|
|
|||
|
|
- 固件版本 `1.7.0-controls.11`。
|
|||
|
|
- RTC Opus 发送时钟改为 48000/960，与接收端一致。
|
|||
|
|
- 保留独立编解码器 16 kHz、单声道、20 ms 和麦克风增益。
|
|||
|
|
- 更新实际 C 分帧及运行时 JSON 回归检查。
|
|||
|
|
|
|||
|
|
## 验证与恢复
|
|||
|
|
|
|||
|
|
- ESP-IDF v5.5.1 编译成功，应用大小 `0x394920`，小于 4 MiB 分区。
|
|||
|
|
- 主机 ASan/UBSan 分帧、碎片输入、错误返回和 JSON 配置检查通过。
|
|||
|
|
- 应用 SHA256：`73ea6d5ed0902873b61a9af742c56dab83d1d70a2aa2ddd2e64dc0cd9e8c23bb`。
|
|||
|
|
- 实机读取分区表确认 A/B 各 4 MiB；otadata 序列 1、VALID、CRC 正确，当前为 ota_0（0x10000）。
|
|||
|
|
- 原应用备份及安装日志位于被 Git 忽略的 `.tmp-microphone-fix/`。只更新应用，保留分区表、otadata、Wi-Fi 与工厂绑定数据。
|
|||
|
|
- 已安装到 COM6，esptool 写入 3,754,272 字节并校验哈希成功。原 ota_0 全分区备份 SHA256：`9aef5ffa4a98d02aedf62052d74a34ec844e90073f731a079cafd3669c6b7df0`。
|
|||
|
|
- 2026-09-26 20:45:33（北京时间）平台已收到 `1.7.0-controls.11` 上报，目标/实际配置版本均为 19，扬声器音量 56。
|
|||
|
|
|
|||
|
|
当前真人复测尚未完成，不将“编译成功”视为语音识别问题已经解决。
|