WebRTC：Chrome浏览器中jitterBufferDelay升高问题排查咨询

1. 锁定Chrome 124版本的WebRTC行为差异 #

• 对比Chrome 123及更早版本在同一设备上的表现，确认问题是否由124版本的API或底层逻辑改动触发。
• 查阅Chrome官方WebRTC更新日志，重点关注媒体流优先级调度、音频抖动缓冲区策略、摄像头启动时的资源分配逻辑相关变更。
• 利用chrome://webrtc-internals/页面，分别在关闭/开启摄像头时抓取完整RTCP统计数据，对比jitterBufferDelay、audioPlayoutDelay、videoCaptureDelay等指标的变化曲线，定位延迟飙升的触发时间点及关联事件。

2. 排查特定设备的硬件与驱动兼容性 #

• 确认设备摄像头型号、驱动版本，尝试更新驱动后复现问题，排除驱动层面的兼容性冲突。
• 检查设备媒体资源分配机制：部分设备启动摄像头时会占用音频相关硬件通道或中断资源，可能导致音频处理线程阻塞（即使整体CPU正常，单个核心/线程可能出现瓶颈）。
• 测试同一设备上的其他WebRTC应用（如Google Meet）是否存在相同问题，判断是应用自身问题还是设备+Chrome的组合问题。

3. 检查应用层WebRTC配置与流处理逻辑 #

• 排查摄像头启动时是否修改过音频流编码参数、QoS策略或RTCRtpSender的优先级设置，这类变更可能触发Chrome抖动缓冲区的异常调整。
• 验证音视频流的时钟源绑定逻辑：确认开启摄像头后，是否错误地将音频流时钟源切换为视频时钟，导致抖动缓冲区延迟累积。
• 检查RTCPeerConnection的iceTransportPolicy、bundlePolicy等配置，确认摄像头启动时是否触发ICE重协商，重协商过程中是否出现音频流临时阻塞。

4. 深挖音频处理管线的细节问题 #

• 检查应用是否使用自定义音频处理模块（如降噪、回声消除），确认摄像头启动时是否触发这类模块的资源占用变化，导致音频帧处理延迟。
• 查看chrome://media-internals/页面，获取音频流的render_delay、decode_delay数据，区分抖动缓冲区延迟是来自网络端还是本地处理端。

5. 针对性代码调试与日志采集 #

• 在应用中添加jitterBufferDelay实时监控日志，记录摄像头启动前后音频流的状态变化，包括RTCRtpReceiver统计数据、媒体轨道状态变更事件。
• 通过chrome://flags/禁用部分WebRTC实验特性（如WebRTC Hardware Acceleration、WebRTC Audio Jitter Buffer），逐一排查是否为特性冲突导致的问题。

内容的提问来源于stack exchange，提问作者davidinteract