车机中 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 通路接口初始化错误导致的。
audio_hw_primary: adev_set_parameters: enter: hfp_enable=true
audio_hw_hfp: origin_audio_extn_hfp_set_parameters: hfp_enable=true
常见思路： 考虑是否写了 data，有没有data传下来，data 是否为mute，上层 app 传递命令是否有错误，BT 协议不匹配，track start 后是不是马上停了。BT控制是否有问题。