72 lines
5.5 KiB
Markdown
72 lines
5.5 KiB
Markdown
# 2025-11-21 Kapi_Rtc 音频/RTC 问题分析与烧录测试总结
|
||
|
||
## 概览
|
||
- 目标：修复开机播报“尖锐/刺耳”、欢迎语速度异常；保证火山 RTC 入房稳定，避免设备重启；比较 Airhub_Rtc_h 参考实现。
|
||
- 结论：问题核心在“开机阶段单声道 PCM 直接写入立体声 I2S 槽”的通道不匹配。保持设备端立体声输出以保证 RTC 连接稳定，同时在软件层将单声道复制为双声道即可消除“尖锐”。
|
||
|
||
## 关键事实与参数
|
||
- 开机 P3 资产参数（生成规格）：采样率 `16000 Hz`、帧时长 `60 ms`、声道 `单声道`、编码 `OPUS`。
|
||
- RTC下行音频参数：
|
||
- OPUS：采样率 `16000 Hz`、帧时长 `60 ms`、单声道（`main/protocols/volc_rtc_protocol.cc:304-320`）。
|
||
- PCM：采样率 `8000 Hz`、帧时长 `20 ms`、单声道（同上，`downlink_is_pcm_` 为真时）。
|
||
- 设备端编解码器（ES8311）初始化：默认立体声槽与双通道输出更稳定。
|
||
- 输出通道：`output_channels_ = 2`（`main/audio_codecs/es8311_audio_codec.cc:12-15`）。
|
||
- I2S 槽：`slot_mode = STEREO`、`slot_mask = BOTH`（`main/audio_codecs/es8311_audio_codec.cc:105-109`）。
|
||
|
||
## 今日修改与实现
|
||
- 在开机阶段的“非管线路径”增加单声道→立体声复制，避免直接将单声道 PCM 写入立体声槽：
|
||
- 代码位置：`main/application.cc:1224-1230`。
|
||
- 逻辑：当 `codec->output_channels()==2` 时，将 `pcm` 复制为交错的 `stereo`（L=R）后输出；否则原样输出。
|
||
|
||
## 现象与测试过程
|
||
- 开机播报尖锐（问题初始）：
|
||
- 路径：开机阶段未启用播放管线，走直接输出（`main/application.cc:1224-1230`）。
|
||
- 原因：单声道 PCM 与设备端立体声槽不匹配，导致通道/槽打包伪像，主观听感“尖锐”。
|
||
- 资产引用：
|
||
- 触发播放：`main/application.cc:531`（`PlaySound(Lang::Sounds::P3_LALA_KAIJIBOBAO);`）。
|
||
- 资产绑定：`main/assets/lang_config.h:275-280`（`LALA_kaijibobao.p3` 二进制绑定）。
|
||
- 文件：`main/assets/zh-CN/LALA_kaijibobao.p3`、`main/assets/zh-CN/LALA_lianjiewangluo.p3`。
|
||
|
||
- 修复后（非管线分支 L/R 复制）：
|
||
- 结果：开机播报“尖锐”消失；欢迎语与 RTC 对话不受影响。
|
||
- 说明：开机阶段保留 `OpusResampler` 的 16k→设备输出采样率（常为 24k）重采样质量，避免最近邻重采样造成伪像。
|
||
|
||
- 测试方案 A：尝试将设备端改为单通道/单声道 I2S 槽（MONO）：
|
||
- 修改：`main/audio_codecs/es8311_audio_codec.cc:13-14` 将输出通道 `2→1`；`110-111` 将 `STEREO→MONO`（左槽）。
|
||
- 现象：RTC 入房超时，日志显示：
|
||
- `VolcRtcProtocol: Wait connect bits=0x0 free_heap=...` 与 `RTC连接超时`（`main/protocols/volc_rtc_protocol.cc:212-216`，终端选中行 Terminal#296-297）。
|
||
- 分析：RTC SDK 音频通道初始化/握手更依赖“标准立体声 I2S 时序”，MONO 改动改变 WS 宽度与槽掩码，仅跑一个槽，导致 SDK 不置位连接成功事件（`VOLC_MSG_CONNECTED` 未触发，`main/protocols/volc_rtc_protocol.cc:260-266`），最终超时。
|
||
- 结论：在当前 SDK/驱动组合下，保持立体声输出更稳；不建议在开机阶段强行改为 MONO 以避免连接不稳定。
|
||
|
||
- 测试方案 B：将 P3 资产改为双声道 OPUS（16kHz/60ms）：
|
||
- 可行性：解码后直接生成双声道 PCM，与立体声槽完全匹配；即使直接输出也不会“尖锐”。
|
||
- 代价：资产体积与解码开销增加，RTC 下行仍是单声道；属于“资源换兼容”，与当前 RTC 参数不匹配，无额外协同收益。
|
||
- 结论：不推荐作为常规方案。
|
||
|
||
## 原理解释与定位
|
||
- 为什么开机解码是单声道 PCM：
|
||
- P3 资产与解码器均为单声道配置（`SetDecodeSampleRate(16000,60)`，`main/application.cc:269-292`）。
|
||
- 为什么立体声输出更稳：
|
||
- 设备端 ES8311 默认按立体声槽/双通道配置，I2S 时钟/槽时序与 DMA 工作稳定性更好；RTC SDK 在连接阶段可能验证或依赖该时序，MONO 改动会破坏这些假设。
|
||
- 为什么对齐 RTC 参数并不能单独解决尖锐：
|
||
- 开机 P3 资产已与 RTC OPUS 参数一致（16k/60ms/单声道），问题不在采样率/帧长，而在“声道与 I2S 槽模式的匹配”。
|
||
|
||
## 代码引用（便于定位）
|
||
- 开机资产播放触发：`main/application.cc:531`。
|
||
- 资产二进制绑定：`main/assets/lang_config.h:275-280`。
|
||
- 直接输出路径与修复点：`main/application.cc:1224-1230`。
|
||
- ES8311 通道与槽配置：`main/audio_codecs/es8311_audio_codec.cc:12-15`、`105-111`、`171-179`。
|
||
- RTC 连接等待与事件位：`main/protocols/volc_rtc_protocol.cc:212-216`（等待位）、`260-266`（连接事件）。
|
||
- RTC 下行类型与采样率识别：`main/protocols/volc_rtc_protocol.cc:304-320`。
|
||
|
||
## 建议与结论
|
||
- 保持设备端立体声输出（保证 RTC 入房稳定）。
|
||
- 保持资产单声道与 RTC 单声道一致；在软件层面针对未启用管线的播放路径增加单声道→立体声复制（已实现）。
|
||
- 不建议将 P3 资产改为双声道；如确有需要，也应评估体积/性能影响。
|
||
- 若要在开机阶段采用 MONO，再在入房后切回 STEREO，需要细致的时序与设备重建流程，风险较高；当前无需引入。
|
||
|
||
## 后续动作
|
||
- 继续观察开机播报听感与 RTC 入房稳定性。
|
||
- 如需进一步优化淡入或重采样质量，可微调淡入时长或评估更高质量重采样算法，但当前修复已满足听感与稳定性目标。
|
||
|