5.5 KiB
5.5 KiB
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_为真时）。
- OPUS：采样率
- 设备端编解码器（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）。
- P3 资产与解码器均为单声道配置（
- 为什么立体声输出更稳：
- 设备端 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 入房稳定性。
- 如需进一步优化淡入或重采样质量，可微调淡入时长或评估更高质量重采样算法，但当前修复已满足听感与稳定性目标。