一、概述

Android 的音频硬件抽象层 (HAL) 可将 android.media 中特定于音频的较高级别的框架 API 连接到底层音频驱动程序和硬件。本部分介绍了有关提升性能的实现说明和提示。

Android 音频架构定义了音频功能的实现方式，并指出实现中所涉及的相关源代码。
在这里插入图片描述

应用框架

应用框架包含应用代码，该代码使用 android.media API 与音频硬件进行交互。在内部，此代码会调用相应的 JNI 粘合类来访问与音频硬件互动的原生代码。

源代码目录：frameworks/base/media/java/android/media/
AudioManager:音频管理器，包括音量管理、AudioFocus管理、音频设备管理、模式管理；
录音：AudioRecord、MediaRecorder；
播放：AudioTrack、MedaiPlayer、SoundPool、ToneGenerator;
编解码：MediaCodec，音视频数据编解码接口。

JNI

与 android.media 关联的 JNI 代码会调用较低级别的原生代码来访问音频硬件。JNI 位于 frameworks/base/core/jni/ 和 frameworks/base/media/jni 中。

Native framework 原生框架

原生框架提供相当于 android.media 软件包的原生软件包，它调用 Binder IPC 代理来访问媒体服务器的音频专属服务。原生框架代码位于 frameworks/av/media/libmedia 中。

原生框架代码位于 frameworks/av/media/libmedia 或frameworks/av/media/libaudioclient中（不同版本，位置有所改变）。

Binder IPC

Binder IPC 代理用于促进跨越进程边界的通信。代理位于 frameworks/av/media/libmedia 中，并以字母“I”开头。

Audio Server 媒体服务器

Audio系统在Android中负责音频方面的数据流传输和控制功能，也负责音频设备的管理。这个部分作为Android的Audio系统的输入/输出层次，一般负责播放PCM声音输出和从外部获取PCM声音，以及管理声音设备和设置（注意：解码功能不在这里实现，在android系统里音频视频的解码是opencore或stagefright完成的，在解码之后才调用音频系统的接口，创建音频流并播放）。Audio服务在Android N(7.0)之前存在于mediaserver中，Android N开始以audioserver形式存在，这些音频服务是与HAL 实现进行交互的实际代码。媒体服务器位于 frameworks/av/services/audioflinger 和frameworks/av/services/audiopolicy中。

Audio服务包含AudioFlinger 和AudioPolicyService：

AudioFlinger：主要负责音频流设备的管理以及音频流数据的处理传输，⾳量计算，重采样、混⾳、⾳效等。
AudioPolicyService:主要负责⾳频策略相关，⾳量调节⽣效，设备选择，⾳频通路选择等。

HAL

HAL 定义了音频服务会调用且您必须实现才能使音频硬件正常运行的标准接口。音频 HAL 接口位于 hardware/libhardware/include/hardware 中。详情可参阅 audio.h。

内核驱动程序

音频驱动程序用于同您的硬件和 HAL 实现进行交互。可以使用高级 Linux 声音架构 (ALSA)、开放声音系统 (OSS) 或自定义驱动程序（HAL 与驱动程序无关）。

注意：如果使用的是 ALSA，建议将 external/tinyalsa 用于驱动程序的用户部分，因为它具有兼容的许可（标准的用户模式库已获得 GPL 许可）。

二、音频系统架构的演进

一个好的系统架构，需要尽可能地降低上层与具体硬件的耦合，这既是操作系统的设计目的，对于音频系统也是如此。音频系统的雏形框架可以简单的用下图来表示：
在这里插入图片描述在这个图中，除去Linux本身的Audio驱动外，整个Android音频实现都被看成了User。因而我们可以认为Audio Driver就是上层与硬件间的“隔离板”。但是如果单纯采用上图所示的框架来设计音频系统，对上层应用使用音频功能是不小的负担，显然Android开发团队还会根据自身的实际情况来进一步细化“User”部分。具体该怎么细化呢？如果是让我们去细化我们该怎么做呢？

首先作为一个操作系统要对外提供可用的API，供应用开发者调用。APP开发者开发的应用我们称APP，我们提供的API姑且叫Framework。如果Framework直接和驱动交互有什么问题呢？

首先是耦合问题，接口和实现耦合，硬件层有任何变动都需要接口层适配，我们增加一层硬件适配层；
资源统一管理的问题，如果多个APP调用相同API使用硬件资源，改怎么分配？增加统一资源管理器，其实就是对应Android系统的Audio Lib层。

细化后我们发现，整个结构对应的就就是Android的几个层次结构，包括应用层、framework层、库层以及HAL层，如下图所示：
在这里插入图片描述

2.1 Lib层

framework层的大多数类，其实只是应用程序使用Android库文件的“中介”，它只是个壳子。因为Android应用采用java语言编写，它们需要最直接的java接口的支持，如果我们的Android系统支持另一种语言的运行时，那么可以提供另一种语言的接口支持（比如Go），这就是framework层存在的意义之一。但是作为“中介”，它们并不会真正去实现具体的功能，或者只实现其中的一部分功能，而把主要重心放在核心库中来完成。比如上面的AudioTrack、AudioRecorder、MediaPlayer和MediaRecorder等等在库中都能找到相对应的类，这些多数是C++语言编写的。

我们再从另一个线索来思考这个问题：我们提供的API供应用层调用，那么这个API最终运行在应用的进程中。如果多个应用同时使用这个功能就会冲突；再一个允许任何一个进程操作硬件也是个危险的行为。那么真相就浮出了水面：我们需要一个有权限管理和硬件交互的进程，需要调用某个硬件服务必须和我这个服务打交道。这就是Android系统的很常用的C/S结构以及Binder存在的主要原因。Android系统中的Server就是一个个系统服务，比如ServiceManager、LocationManagerService、ActivityManagerService等等，以及管理图像合成的SurfaceFlinger，和今天我们今天介绍的音频服务AudioFlinger和AudioPolicyService。它们的代码放置在frameworks/av/services/audioflinger，生成的最主要的库叫做libaudioflinger。

这里也提到了分析源码除以模块为线索外的另一种线索以进程为线索。库并不代表一个进程，但是进程则依赖于库来运行。虽然有的类是在同一个库中实现的，但并不代表它们会在同一个进程中被调用。比如AudioFlinger和AudioPolicyService都驻留于名为mediaserver的系统进程中;而AudioTrack/AudioRecorder和MediaPlayer/MediaRecorder只是应用进程的一部分，它们通过binder服务来与其它audioflinger等系统进程通信

2.2 HAL层

硬件抽象层顾名思义为适配不同硬件而独立封装的一层，音频硬件抽象层的任务是将AudioFlinger/AudioPolicyService真正地与硬件设备关联起来，但又必须提供灵活的结构来应对变化。

从设计上来看，硬件抽象层是AudioFlinger直接访问的对象。这里体现了两方面的考虑：

一方面AudioFlinger并不直接调用底层的驱动程序;
另一方面，AudioFlinger上层(包括和它同一层的MediaPlayerService)的模块只需要与它进行交互就可以实现音频相关的功能了。

AudioFlinger和HAL是整个架构解耦的核心层，通过HAL层的audio.primary等库抹平音频设备间的差异，无论硬件如何变化，不需要大规模地修改上层实现，保证系统对外暴露的上层API不需要修改，达成高内聚低耦合。而对厂商而言，在定制时的重点就是如何在这部分库中进行高效实现了。

举个例子，以前Android系统中的Audio系统依赖于ALSA-lib，但后期就变为了tinyalsa，这样的转变不应该对上层造成破坏。因而Audio HAL提供了统一的接口来定义它与AudioFlinger/AudioPolicyService之间的通信方式，这就是audio_hw_device、audio_stream_in及audio_stream_out等等存在的目的，这些Struct数据类型内部大多只是函数指针的定义，是一个个句柄。当AudioFlinger/AudioPolicyService初始化时，它们会去寻找系统中最匹配的实现(这些实现驻留在以audio.primary.*,audio.a2dp.*为名的各种库中)来填充这些“壳”，可以理解成是一种“多态”的实现。

三、Linux平台下的两种主要的音频驱动架构接收

3.1 OSS(Open Sound System)

早期Linux版本采用的是OSS框架，它也是Unix及类Unix系统中广泛使用的一种音频体系。OSS既可以指OSS接口本身，也可以用来表示接口的实现。OSS的作者是Hannu Savolainen，就职于4Front Technologies公司。由于涉及到知识产权问题，OSS后期的支持与改善不是很好，这也是Linux内核最终放弃OSS的一个原因。

另外，OSS在某些方面也遭到了人们的质疑，比如：

对新音频特性的支持不足;
缺乏对最新内核特性的支持等等。

当然，OSS做为Unix下统一音频处理操作的早期实现，本身算是比较成功的。它符合“一切都是文件”的设计理念，而且做为一种体系框架，其更多地只是规定了应用程序与操作系统音频驱动间的交互，因而各个系统可以根据实际的需求进行定制开发。总的来说，OSS使用了如下表所示的设备节点：

设备节点	说明
/dev/dsp	向此文件写数据à输出到外放Speaker向此文件读数据à从Microphone进行录音
/dev/mixer	混音器，用于对音频设备进行相关设置，比如音量调节
/dev/midi00	第一个MIDI端口，还有midi01,midi02等等
/dev/sequencer	用于访问合成器（synthesizer），常用于游戏等效果的产生

3.2 ALSA(Advanced Linux Sound Architecture)

ALSA是Linux社区为了取代OSS而提出的一种框架，是一个源代码完全开放的系统(遵循GNU GPL和GNU LGPL)。ALSA在Kernel 2.5版本中被正式引入后，OSS就逐步被排除在内核之外。当然，OSS本身还是在不断维护的，只是不再为Kernel所采用而已。

ALSA相对于OSS提供了更多，也更为复杂的API接口，因而开发难度相对来讲加大了一些。为此，ALSA专门提供了一个供开发者使用的工具库，以帮助他们更好地使用ALSA的API。根据官方文档的介绍，ALSA有如下特性：

高效支持大多数类型的audio interface(不论是消费型或者是专业型的多声道声卡)
高度模块化的声音驱动
SMP及线程安全(thread-safe)设计
在用户空间提供了alsa-lib来简化应用程序的编写
与OSS API保持兼容，这样子可以保证老的OSS程序在系统中正确运行

ALSA主要由下表所示的几个部分组成：

Eliment	Description
alsa-driver	内核驱动包
alsa-tools	包含一系列工具程序
alsa-utils	包含了很多使用的小程序，比如alsactl:用于保存设备设置amixer:是一个命令行程序，用于音量和其他声音控制alsamixer的ncurses版acconnect和aseqview:制作MIDI连接，以及检查已经连接的端口列表,aplay和arecord:两个命令行程序，分别用于播放和录制多种格式的音频
alsa-plugins	插件包，比如jack，pulse，maemo
alsa-oss	用于兼容OSS的模拟包
pyalsa	用于编译python版本的alsa lib
alsa-lib	用户空间函数
alsa-firmware	音频固件支持包
Alsa主要的文件节点如下：

Information Interface (/proc/asound)
Control Interface (/dev/snd/controlCX)
Mixer Interface (/dev/snd/mixerCXDX)
PCM Interface (/dev/snd/pcmCXDX)
Raw MIDI Interface (/dev/snd/midiCXDX)
Sequencer Interface (/dev/snd/seq)
Timer Interface (/dev/snd/timer)

Android的TinyALSA是基于Linux ALSA基础改造而来。一看“Tiny”这个词，我们应该能猜到这是一个ALSA的缩减版本。实际上在Android系统的其它地方也可以看到类似的做法——既想用开源项目，又嫌工程太大太繁琐，怎么办？那就只能瘦身了，于是很多Tiny-XXX就出现了。

在早期版本中，Android系统的音频架构主要是基于ALSA的，其上层实现可以看做是ALSA的一种“应用”。后来可能是由于ALSA所存在的一些不足，Android后期版本开始不再依赖于ALSA提供的用户空间层的实现。HAL层最终依赖alsa-lib库与驱动层交互。

Android 音频(Audio)架构