AndroidAudioSystem.doc

Android 音频系统
1. 系统架构
Android的音频系统拥有一个比较标准和健全的架构，从上层应用，java framework服务AudioMananger，本地服务AudioFlinger，抽象层AlsaHAL，本地库，再调用external的tinyalsa外部支持库，最后到底层驱动的codec。

Java服务AudioManager作为服务端，本地服务AudioFlinger作为客户端，两者通过Binder机制交互。AudioFlinger对硬件功能的具体实现交给硬件抽象层AlsaHAL完成。抽象层可以调用本地标准接口，或者直接调用Tinyalsa库去操作底层驱动。

详细调用过程如下图：

简单说来，轨迹如下：
Java端发起调用，MediaPlayer会转至MediaPlayerService，然后会调用相应的解码工具解码后创建AudioTrack，所有待输出的AudioTrack在AudioFlinger::AudioMixer里合成，然后通过AudioHAL(AudioHardwareInterface的实际实现者)传至实际的硬件来实现播放。

2. AudioFlinger
AudioFlinger是android中的一个service，在android启动时就已经被加载。AudioFlinger向下访问AudioHardware，实现输出音频数据，控制音频参数。同时，AudioFlinger向上通过IAudioFinger接口提供服务。所以，AudioFlinger在Android的音频系统框架中起着承上启下的作用，地位相当重要。
AudioFlinger的类结构
下面的图示描述了AudioFlinger类的内部结构和关系：

· IAudioFlinger接口
    这是AudioFlinger向外提供服务的接口，例如openOutput，openInput，createTrack，openRecord等等，应用程序或者其他service通过ServiceManager可以获得该接口。该接口通过继承BnAudioFlinger得到。
· ThreadBase
在AudioFlinger中，Android为每一个放音/录音设备均创建一个处理线程，负责音频数据的I/O和合成，ThreadBase是这些线程的基类，所有的播放和录音线程都派生自ThreadBase
· TrackBase
应用程序每创建一个音轨（AudioTrack/AudioRecord），在AudioFlinger中都会创建一个对应的Track实例，TrackBase就是这些Track的基类，他的派生类有：
PlaybackTread::Track    // 用于普通播放，对应于应用层的AudioTrack
PlaybackThread::OutputTrack    // 用于多重设备输出，当蓝牙播放开启时使用
RecordThread::RecordTrack    // 用于录音，对应于应用层的AudioRecord
· 播放
默认的播放线程是MixerThread，它由AudioPolicyManager创建，最终会进入AudioFlinger的openOut函数。

3. AudioTrack和AudioFlinger的通信机制
通常，AudioTrack和AudioFlinger并不在同一个进程中，它们通过android中的binder机制建立联系。
AudioTrack主要是用来播放声音的，AudioTrack贯穿了JAVA层,JNI层和Native层。
下面这张图展示了他们两个的关系：

我们可以这样理解这张图的含义：
audio_track_cblk_t实现了一个环形FIFO；
AudioTrack是FIFO的数据生产者；
AudioFlinger是FIFO的数据消费者。
1) 建立联系的过程
下面的序列图展示了AudioTrack和AudioFlinger建立联系的过程：

2) FIFO的管理
audio_track_cblk_t
audio_track_cblk_t这个结构是FIFO实现的关键，该结构是在createTrack的时候，由AudioFlinger申请相应的内存，然后通过IMemory接口返回AudioTrack的，这样AudioTrack和AudioFlinger管理着同一个audio_track_cblk_t，通过它实现了环形FIFO，AudioTrack向FIFO中写入音频数据，AudioFlinger从FIFO中读取音频数据，经Mixer后送给AudioHardware进行播放。
l audio_track_cblk_t的主要数据成员：
user -- AudioTrack当前的写位置的偏移
userBase -- AudioTrack写偏移的基准位置，结合user的值方可确定真实的FIFO地址指针
server -- AudioFlinger当前的读位置的偏移
serverBase -- AudioFlinger读偏移的基准位置，结合server的值方可确定真实的FIFO地址指针
frameCount -- FIFO的大小，以音频数据的帧为单位，16bit的音频每帧的大小是2字节
buffers -- 指向FIFO的起始地址
out -- 音频流的方向，对于AudioTrack，out=1，对于AudioRecord，out=0
l audio_track_cblk_t的主要成员函数：
framesAvailable_l()和framesAvailable()用于获取FIFO中可写的空闲空间的大小，只是加锁和不加锁的区别。
framesReady()用于获取FIFO中可读取的空间大小。

3) IMemory接口
在createTrack的过程中，AudioFlinger会根据传入的frameCount参数，申请一块内存，AudioTrack可以通过IAudioTrack接口的getCblk()函数获得指向该内存块的Imemory 接口，然后AudioTrack通过该IMemory接口的pointer()函数获得指向该内存块的指针，这块内存的开始部分就是audio_track_cblk_t结构，紧接着是大小为frameSize的FIFO内存。

4. AudioPolicyService
AudioPolicyService是Android音频系统的两大服务之一，另一个服务是AudioFlinger，这两大服务都在系统启动时有MediaSever加载。
AudioPolicyService主要完成以下任务：
· JAVA应用层通过JNI，经由IAudioPolicyService接口，访问AudioPolicyService提供的服务
· 输入输出设备的连接状态
· 系统的音频策略（strategy）的切换
· 音量/音频参数的设置
AudioPolicyService的构成
下面这张图描述了AudioPolicyService的静态结构：

进一步说明:
1) AudioPolicyService继承了IAudioPolicyService接口，这样AudioPolicyService就可以基于Android的Binder机制，向外部提供服务；
2) AudioPolicyService同时也继承了AudioPolicyClientInterface类，他有一个AudioPolicyInterface类的成员指针mpPolicyManager，实际上就是指向了AudioPolicyManager；
3) AudioPolicyManager类继承了AudioPolicyInterface类以便向AudioPolicyService提供服务，反过来同时还有一个AudioPolicyClientInterface指针，该指针在构造函数中被初始化，指向了AudioPolicyService，实际上，AudioPolicyService是通过成员指针mpPolicyManager访问AudioPolicyManager，而AudioPolicyManager则通过AudioPolicyClientInterface（mpClientInterface）访问AudioPolicyService；
4) AudioPolicyService有一个内部线程类AudioCommandThread，顾名思义，所有的命令（音量控制，输入、输出的切换等）最终都会在该线程中排队执行；
l 输入输出设备管理
音频系统为音频设备定义了一个枚举：AudioSystem::audio_devices，例如：DEVICE_OUT_SPEAKER，DEVICE_OUT_WIRED_HEADPHONE，DEVICE_OUT_BLUETOOTH_A2DP，DEVICE_IN_BUILTIN_MIC，DEVICE_IN_VOICE_CALL等等，每一个枚举值其实对应一个32bit整数的某一个位，所以这些值是可以进行位或操作的，
l 音量管理
AudioPolicyManager提供了一下几个与音量相关的函数：
initStreamVolume(AudioSystem::stream_type stream, int indexMin, int indexMax)
setStreamVolumeIndex(AudioSystem::stream_type stream, int index)
getStreamVolumeIndex(AudioSystem::stream_type stream)
AudioService.java中定义了每一种音频流的最大音量级别：
 /** @hide Maximum volume index values for audio streams */ 
private int[] MAX_STREAM_VOLUME = new int[] {  
5,  // STREAM_VOICE_CALL  
7,  // STREAM_SYSTEM  
7,  // STREAM_RING  
  15, // STREAM_MUSIC  
  7,  // STREAM_ALARM  
7,  // STREAM_NOTIFICATION  
15, // STREAM_BLUETOOTH_SCO  
7,  // STREAM_SYSTEM_ENFORCED  
15, // STREAM_DTMF  
15  // STREAM_TTS  
}; 
由此可见，电话铃声可以有7个级别的音量，而音乐则可以有15个音量级别，java的代码通过jni，最后调用AudioPolicyManager的initStreamVolume()，把这个数组的内容传入AudioPolicyManager中，这样AudioPolicyManager也就记住了每一个音频流的音量级别。应用程序可以调用setStreamVolumeIndex设置各个音频流的音量级别，setStreamVolumeIndex会把这个整数的音量级别转化为适合人耳的对数级别，然后通过AudioPolicyService的AudioCommandThread，最终会将设置应用到AudioFlinger的相应的Track中。
l 音频策略管理
  我想首先要搞清楚stream_type，device，strategy三者之间的关系：
AudioSystem::stream_type音频流的类型，一共有10种类型。
AudioSystem::audio_devices音频输入输出设备，每一个bit代表一种设备，见前面的说明。
AudioPolicyManager::routing_strategy 音频路由策略，可以有4种策略。

getStrategy(stream_type)根据stream type，返回对应的routing strategy值，getDeviceForStrategy()则是根据routing strategy，返回可用的device。Android把10种stream type归纳为4种路由策略，然后根据路由策略决定具体的输出设备。