1. 问题描述

场景：TV 连接蓝牙音响，播放在线或本地视频  

现象：声音与画面明显不同步，音频滞后于视频约 1 秒，主观体验差  

概率：必现  

预期结果：音视频同步播放 

实际结果：视频比声音延后约1秒

 

2. 分析过程

2.1 根因分析

2.1.1 蓝牙HAL向音频框架上报音频BUF深度耗时

OpenHarmony 音频框架在同步音视频（蓝牙播放音频）时，会向 HAL 层查询当前蓝牙音频缓冲区深度的延时值（`GetLatency`）。蓝牙音频 HAL 在 `audio_render.cpp` 中通过 `AudioRenderGetLatency` 函数计算并上报该值：

其中：

- `periodSize`：由 `DEEP_BUFFER_RENDER_PERIOD_SIZE` 决定

- `periodCount`：由 `DEEP_BUFFER_RENDER_PERIOD_COUNT` 常量决定

- `byteRate`：等效采样率，由 `DEFAULT_RENDER_SAMPLING_RATE` 决定

该延迟值被音视频同步模块用于计算视频画面的展示时间戳。如果上报的延迟远大于真实延迟，则视频播放将被人为延迟，造成画面滞后于声音。

 

2.1.2 原有参数导致的延迟

原代码中的默认配置为：

constexpr int DEEP_BUFFER_RENDER_PERIOD_SIZE = 4096;

constexpr int DEEP_BUFFER_RENDER_PERIOD_COUNT = 8;

代入公式计算上报延迟：

(8 × 4096 × 1000) / 48000 ≈ 682 ms

蓝牙音频的真实延迟通常在 100 ~ 200 ms 之间。HAL 上报的 682 ms 远超实际值，导致音视频同步机制错误地将视频画面推迟了近 700 ms，主观感受即声音比画面早约 1 秒。

 

3. 解决方案

3.1 修改内容

调整 `audio_adapter.cpp` 中的两个常量：

constexpr int DEEP_BUFFER_RENDER_PERIOD_SIZE = 2048;  // 原值 4096

constexpr int DEEP_BUFFER_RENDER_PERIOD_COUNT = 4;    // 原值 8

修改后的上报延迟为：

上报延迟   = (4 × 2048 × 1000) / 48000 ≈ 170 ms

 

3.2 效果验证

音视频同步：播放 1024×576@25fps 及 1080p@50fps 视频，主观感受音画同步良好，无原先的约 1 秒滞后。

 

3.3 原理总结

该方案的本质是修正 HAL 层向音视频框架上报蓝牙音频BUF深度的延迟值，从而让框架正确计算视频渲染时刻。同时，保留适当缓冲以保证蓝牙传输的抗抖动能力。参数选择在音画同步与播放流畅性之间取得了平衡，满足 TV 视频播放场景的要求。