android音频浅谈

转载自：http://blog.csdn.net/reiliu/article/details/8774749

Android Framework的音频子系统中，每一个音频流对应着一个AudioTrack类的一个实例，每个AudioTrack会在创建时注册到AudioFlinger中，由AudioFlinger把所有的AudioTrack进行混合（Mixer），然后输送到AudioHardware中进行播放。AudioTrack和AudioFlinger的通信机制通常，AudioTrack和AudioFlinger并不在同一个进程中，它们通过android中的binder机制建立联系。

Android音频处理的基本接口

 

在Android开发中，根据不同的场景，出于冲突处理策略的考虑，开发者需要利用不同的接口来进行音频资源的播放。

 

AudioManager为上层应用提供了声音设置管理接口.

 

AudioService为所有的音频相关的设置提供服务。他定义了了一个AudioSystemThread 的类，用来监控音频控制相关的信号，当有请求时，它会通过调用AudioSystem 的接口实现音频的控制，这里的消息处理是异步的。此外在AudioService还抽象出了一套发送音频控制信号的接口为AudioManager提供支持。AudioManager通过音频服务，为上层提供了音量和铃声模式控制的接口，铃声模式控制包括扬声器、耳机、蓝牙等是否打开，麦克风是否静音等。在开发多媒体应用时会经常用到AudioManager,关于Android AudioManager音量控制流程。

AudioSystem提供了音频系统的基本类型定义，以及基本操作的接口。

对于音调，可以通过ToneGenerator来播放；ToneGenerator提供了对DTMF音（ITU-T Q.23），以及呼叫监督音（3GPP TS 22.001）、专用音（3GPP TS 31.111）中规定的音频的支持，根据呼叫状态和漫游状态，该文件产生的音频路径为下行音频或者传输给扬声器或耳机。

对于提示音，可以通过Ringtone来播放；Ringtone和RingtoneManager为铃声、提示音、闹钟等提供了快速播放，以及管理接口。实质是对媒体播放器提供了一个简单的封装。

对于录音功能，则需要通过MediaRecorder和AudioRecord等来进行音频记录。

除了这些直接的音频类外，对于音量调节、音频设备的管理等，Android还提供了相关的类来处理。

对于游戏中的音频资源，可以通过SoundPool来播放。

SoundPool能够播放音频流的组合音，这对游戏应用而言显然非常有用。SoundPool可以从APK包中的资源文件或者文件系统中的文件将音频资源加载到内存中。在底层的实现上，SoundPool通过媒体播放服务可以将音频资源解码为一个16bit的单声道或者立体声的PCM流，这使得应用避免了在回放过程中进行解码造成的延迟。除了回放过程中延迟小的优点外，SoundPool还能够对一定数量的音频流进行同时播放。当要播放的音频流数量超过SoundPool所设定的最大值时，SoundPool将会停止已播放的一条低优先级的音频流。SoundPool最大播放音频流数量的设置，可以避免CPU过载和影响UI体验。

Android平台中关于音频的播放还有另一种方式是MediaPlayer。MediaPlayer得特点是同一时间只能播放一个，适合较长但是对时间要求不高的情况。

 

二、MediaServer分析

 MediaServer是整个android中media部分的核心和灵魂。几乎所有与多媒体播放相关的内容都放在这里。包括了音视频的编解码以及显示输出。

1. 先初始化AudioFlinger

其初始化通过AudioFlinger的父类BindService创建唯一的AudioFlinger实例。

2. 然后初始化MediaPlayerService

3. 最后初始化AudioPolicyService

 

三、AudioPolicyService 和 AudioPolicyManager分析

AudioPolicyService是Android音频系统的两大服务之一，另一个服务是AudioFlinger，这两大服务都在系统启动时有 MediaSever加载。

AudioPolicyService主要完成以下任务：

l  JAVA应用层通过JNI，经由IAudioPolicyService接口，访问AudioPolicyService提供的服务

l  输入输出设备的连接状态

l  系统的音频策略（strategy）的切换

l  音量/音频参数的设置

AudioPolicyManager

  AudioPolicyService的很大一部分管理工作都是在AudioPolicyManager中完成的。包括音量管理，音频策略（strategy）管理，输入输出设备管理。

通过AudioPolicyService的 AudioCommandThread，最终会将设置应用到AudioFlinger的相应的Track中。

 

四、 AudioFlinger分析

AudioFlinger负责管理每个音轨AudioTrack及RecordTrack，主音量控制，每种声音流的属性设置，设备控制，音效控制。AudioFlinger是android中的一个service，在android启动时就已经被加载。

 

播放线程实际上是MixerThread的一个实例，会把该线程中的各个Track进行混合，必要时还要进行ReSample(重采样)的动作，转换为统一的采样率（44.1K），然后通过音频系统的AudioHardware层输出音频数据。

 

SRC[Sample Rate Converter，采样频率转换] SRC的作用就是改变信号的采样率，低采样率往高采样率转换时就是一个重采样的过程，重采样对象不再是原始信号，而是这个低采样率的信号，因为采样率不够需要插入更多的采样点以达到需要的采样率和采样大小。

 

三种平台的音频架构对比

一、android平台

 

Android使用的是为智能终端专门制定的ALSA（AdvancedLinux Sound Architecture，高级Linux声音架构）框架。

从Android的音频架构及流程分析，由于其驱动库位于核心层，也就意味着音频设备厂商、用户无法象PC平台那样安装驱动来改善音质。我们在实际的应用中也能感受到，Android设备音质普遍偏差。音质出现偏差一个主要的问题是处在SRC这里。低采样率往高采样率转换时就是一个重采样的过程，重采样对象不再是原始信号，而是这个低采样率的信号，因为采样率不够需要插入更多的采样点以达到需要的采样率和采样大小

理论上SRC可以通过更换算法来实现音质提升，但却不太现实，SRC需要大量的浮点运算的资源，即便有了高质量的SRC算法，其运算也是以牺牲设备性能和耗电量为代价的，实用性差。

 

二、windowsphone平台

 

通用音频架构（UAA）

UAA分为独占模式和共享模式，它最大程度的降低了音频设备驱动对系统稳定性的影响，而且还能够增加信号处理流程的透明度，处理环节可以得到控制，在理论上说，它可以实现更加优秀的音质，也能非常显著的提升系统响应速度，大幅减低延时

应用程式在一般情况下都是走Shared Mode（共享模式）那条路径，这个路径被称作通道，根据上面关于共享模式的介绍，所有的声音讯号都会转送至Audio Engine（音效引擎）部分，有软件混音动作，就可能会经过SRC，使得声音出现偏差。而当应用程序发出使用独占模式的需求后，系统会切断共享模式这一条路径，声音讯号就会直接送达Kernel Mode最后到达底层的音频设备后输出，音频设备在此时也会完全100%配合独占模式送来的音频格式进行处理。

三、iOS平台

我们再把目光投向iOS，iOS非常封闭，我们甚至无法获知其架构的具体构成，但iOS设备不存在硬件设备多样性的问题，因此要实现更好音质也会更加简单。iOS可以实现针对性的开发和改良，以实现更好的音质。实际情况也是如此，目前为止，还没有一款Android设备的音质可以媲美任意一款iOS设备，这种差距，我们认为不是来自硬件，而是操作系统。