Android Audio System

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进行播放。 · 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 · 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，顾名思义，所有的命令（音量控制，输入、输出的切换等）最终都会在该线程中排队执行； · 输入输出设备管理 音频系统为音频设备定义了一个枚举：AudioSystem::audio_devices，例如：DEVICE_OUT_SPEAKER，DEVICE_OUT_WIRED_HEADPHONE，DEVICE_OUT_BLUETOOTH_A2DP，DEVICE_IN_BUILTIN_MIC，DEVICE_IN_VOICE_CALL等等，每一个枚举值其实对应一个32bit整数的某一个位，所以这些值是可以进行位或操作的， · 音量管理 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中。 · 音频策略管理   我想首先要搞清楚stream_type，device，strategy三者之间的关系： AudioSystem::stream_type音频流的类型，一共有10种类型。 AudioSystem::audio_devices音频输入输出设备，每一个bit代 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 一种设备，见前面的说明。 AudioPolicyManager::routing_strategy 音频路由策略，可以有4种策略。 getStrategy(stream_type)根据stream type，返回对应的routing strategy值，getDeviceForStrategy()则是根据routing strategy，返回可用的device。Android把10种stream type归纳为4种路由策略，然后根据路由策略决定具体的输出设备。