车机中 Android Audio 音频常见问题分析方法实践小结

文章目录

前言
1. 无声
2. 断音
3. 杂音
4. 延迟播放
5. 焦点问题
6. 无声问题(连上 BT )
其他完善中……

前言

本文主要总结了一下车机开发中遇到的 Audio 有关的问题，同时参考网上的一案例，由于Audio 模块出现音频问题的场景很多，对每一个出现的问题，主要做思路上的分析，细节上不做进一步纠结，后期慢慢完善，先做一个框架性的总结。

1. 无声

实例：现象：蓝牙通话时，车机和手机均无声。

原因分析：

由于车机端断开了SCO（电话音频）的连接，所以车机端没有声音，手机端的 SCO 也没有建立。

常见思路：

整机无声(bt和手机一起播放声音时)：通路策略切错；BT状态不对；data往BT走，BT 断开无法播放；全局静音；音量为 0；往下写 data 时中间出现了 mute ；

整机无声(只有手机)：可能是播放设备没有正确选择，输出设备策略选择问题

A2DP无声：正常情况数据走 A2DP，实际上走了 SCO，但 SCO 无法接收，所以没有声音

SCO无声：网络原因；没有打开 mic

2. 断音

实例现象：车机连接蓝牙耳机，播放视频声音输出断断续续。

原因分析：

Framework端分析：Android dump pcm 文件，播放声音正常。排除Framework 端的问题，转耳机硬件分析。

耳机端分析：从 btsnoop 里解析出来车机发出的音频无卡顿，数据帧也是饱和的，耳机端如果听到是断断续续有卡顿的话，是耳机的问题，换个耳机试。

在这里插入图片描述

常见思路：

在其他平台如 MTK，audio dump 中 resample in 节点有断音，可能是 underrun，原因是 APP 写数据太慢，这种情况无法优化，只能三方解决。

在往下走的其他节点出现断音，通过调整 buffer 大小来解决（buffer一般情况不动，减少buffer会出现断音，增大buffer会出现延迟）。

数据写快了，写慢了都可能造成断音。(实际开发目前未遇到，后期遇到了再补充案例)。

3. 杂音

实例现象：连接蓝牙耳机，刚打开视频 App 播放的时候会有杂音

原因思路：爆破音,杂音，需要提供 audio dump, tcpdump 以太网等日志结合分析。

Framework 分析：

连接耳机和不连接耳机都会有杂音的情况出现，只是喇叭不容易听出来，底层日志信息看视频App 中 AudioTrack 都有 underrun 提示。
HAL　底层尝试加大视频播放器　AudioTrack buffer 大小后，仍然存在此问题，已说明是应用层写数据慢导致。
从audio dump 数据来看，杂音处数据只漏掉一两帧，但连续出现多次，导致出现“滋滋"的杂声。说明出问题时，写入数据处于断流的临界点附件。

分析结论：需视频 App端进一步分析部数据写入慢问题。

常见思路：

通过 audio dump定位，在节点 af_track 就有杂音属于是 APP 写下来的数据就有杂音。资源文件就有杂音，无法优化。资源文件没有杂音，可能是在上层太忙，buffer太小，出现了underrun，造成了数据损坏，这种情况通过调整 buffer来解决，调整 frameCount，调大延时变长，request 太多，但是写的少，write 的数据就有可能丢失。杂音在中间，如effect，resample 等情况。
分析 dump，确定出现问题的节点，杂音分析 buffer，断音一般为underrun (上层app写数据太慢，供不应求，会造成断音或者杂音，解决方案一般是调整buffer大小，buffer调大)3秒一般是 standby。

4. 延迟播放

实例现象：CarPlay 中切换音乐歌曲延迟较高,大概 3秒。

原因分析：网络连接下延迟 1~3 秒属于正常现象，不同手机和不同的播放器在不同网络下表现不同。该延迟由手机端控制，车机端无法优化。

常见思路：看最开始 write 数据的时间，可能最开始写的数据就是空的。或者是延迟的写数据的时间。

5. 焦点问题

这是一个比较大的模块，涉及到焦点策略，如混音、打断、禁止等策略。各 App 端需要和系统端的策略达成一致，另外，由于车机上有很多的第三方应用，有些提供方不方便维护，要么就出现的问题维持现状，要么系统端 Audio 这边适配，具体问题再进一步分析。后面我会单独总结一些常见的音频焦点问题。

常见思路：排查关键字： CarAudioFocus、MediaFocus 等分析焦点栈，再结合焦点策略进一步分析焦点的申请与释放、消息的传递给 AudioManager 是否正确，App 端是否根据焦点变化处理了相关逻辑等。

6. 无声问题(连上 BT )

实例现象：蓝牙电话无声音

思路分析：

Framework 端先确认通道是否打开，采样率是否正确设置，与底层传递的参数是否正确，具体参数需要和底层沟通好。如关键字分析：

audio_hw_primary: adev_set_parameters: enter: open_source=0:2

audio_hw_primary: adev_set_parameters: enter: hfp_set_sampling_rate=48000

audio_hw_hfp: origin_audio_extn_hfp_set_parameters: hfp_enable=true

蓝牙端分析：

结合 log 分析，蓝牙电话调用的原生 hfp 通路，开机初始化时 hfp 通路接口初始化错误导致的。