解析Android Audio音频模块、框架、架构设计

Android Audio音频常见问题分析方法

(1).无声

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

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

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

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

(2).断音

在MTK平台中，audio dump中resample in节点有断音，可能是underrun，原因是APP写数据太慢，这种情况无法优化，只能三方解决。在往下走的其他节点出现断音，通过调整buffer大小来解决（buffer一般情况不动，减少buffer会出现断音，增大buffer会出现延迟）。数据写快了，写慢了都可能造成断音

(3).杂音

通过audio dump定位，在节点af_track就有杂音属于是APP写下来的数据就有杂音。资源文件就有杂音，无法优化。资源文件没有杂音，可能是在上层太忙，buffer太小，出现了underrun，造成了数据损坏，这种情况通过调整buffer来解决，调整frameCount，调大延时变长，request太多，但是写的少，write的数据就有可能丢失。杂音在中间，如effect，resample等情况

(4).设备切换

耳机插拔，蓝牙，不同stream不同的route，不同的volume。track start后马上暂停了

(5).延迟播放

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

(6).焦点问题

哪一个请求焦点是最新的，焦点就在哪儿

(7).多路录音

(8).有线耳机

(9).蓝牙

(10).控制类问题

如播放、暂停等操作，考虑BT协议的问题

(11).播放时间有问题

分析第一次write date的地方(track write to buffer)

(12).声音在不同应用中切换的问题

分析MediaFocus，谁最后请求，给谁focus，类似栈

(13).无声问题(连上BT)

考虑是否写了data，有没有data传下来，data是否为mute，上层app传递命令是否有错误，BT协议不匹配，track start后是不是马上停了。BT控制是否有问题

(14).音质问题

首先分析dump，确定出现问题的节点，杂音分析buffer，断音一般为underrun(上层app写数据太慢，供不应求，会造成断音或者杂音，解决方案一般是调整buffer大小，buffer调大)3秒一般是standby

(15).录音

一般考虑多路录音，多个record抢占mic

(16).路由问题

(17).BT audio分析总结

分析audio dump，确定写给BT的data是否正常，MTK平台Android原生架构分析threadloop write节点，高通平台分析QXDM 1586节点，从dump确定问题大概位置

分析systrace 确定性能

AudioFocus状态(用于播放或者音量异常的情况)

AudioTrack是否正常创建

bt连接是否正常

通路异常，setMode，setSpeakerphoneOn等都会影响设备选择，sco调用流程是否正常

APM setOutputDevice时已经选择了预期的设备，则是驱动问题

定制版安全手机

Android Audio音频框架图

Android Audio软件架构图

Android Audio音频模块

从AudioTrack到AudioFlinger

Android Audio音频框架图

AudioTrack、PlaybackThread、输出流设备三者的对应关系

AudioTrack和AudioFlinger的类图，AudioFlinger的主要类及其关系、AudioTrack与AudioFlinger之间的联系

AudioFlinger拥有的PlaybackThread、Track、TrackHandle实例

以上关于Android Audio音频模块、框架、架构相关图片来源于网络

编辑：黄飞