安卓系统音频开发经验积累

前言

本文主要记录一些平时工作中遇到的问题，以及一些音频经验，解决思路等等。分为四大块介绍，首先会介绍平时工作中都会遇到哪些高频问题，以及解决问题的思路，后面会分别介绍fwk， hal， kernel 遇到的一些问题记录和修改方案。持续更新~

一、音频头脑风暴

画一个音频相关的头脑风暴图

二、FWK问题

1、pop音

场景1：闹钟响起时摘下蓝牙耳机，spk高概率出现pop音。

从pcm看在切设备结束的位置有一个pop， 从日志看spk+a2dp -> spk 的时候有音频流检测机制打印的日志，两帧数据间隔时间太久（35ms），一般情况，这需要找fwk去分析，为什么这两帧数据，写数据间隔这么久，
一般框架会分析日志中是否有underrun等打印，还有需要分析trace， 去看这两帧数据为什么间隔这么久。
从trace分析，发现间隔太久是因为框架在等hal 切设备（createaudiopach）结束返回给框架，框架才会往下写数据。这个时候有需要hal继续分析，为什么hal切设备时间耗时这么久。

hal分析有几个思路：
1， 分析这个时候是否是正常的切设备，是否需要切设备。
2、如果此时切设备时必须的。那么继续分析trace， 看createaudiopatch为什么卡这么久， 一般trace可以看几个点，看createaudiopatch的时候，是否cpu跑满？是否是cpu调度不过来？等等， 如果trace上看不到什么异常。可以继续分析日志。
3、在我们切设备的时候，框架为了不产生pop， 都会做mute操作。我们可以继续查看框架是否进行mute？ mute时间是否正常？mute时间是否能包住切设备所用时间？
从我们的日志看，框架是有mute 244ms，并且mute时间比切设备时间大， 那么按道理来说这个时间不应该产生pop音了。为什么还会有pop？这个pop从哪里来的？

4、没有思路后，我们可以怀疑是否有算法histen， sws等等影响？

蓝牙过histen算法，我们关闭histen算法后验证无问题。那么为什么日志中切设备时间小于mute时间，histen算法是怎么导致的pop呢？

结论：
日志中看到的mute时间能包住createaudiopatch，不能完全相信createaudiopatch 完全就在mute时间内，可能有些流程和算法等等，会导致切设备时间滞后或提前，最终产生pop

问题解决：
框架对createaudiopatch进行delay延时50ms， 推迟createaudiopatch的时间， 验证后问题解决
修改在audiopolicymanigermngt.cpp中修改outputdevice接口中，有对delayMs进行修改

2、卡顿

3、无声

4、

三、HAL问题

四、KERNEL问题