Android音频系统

概述： 基础音频知识

音频的录制、存储和回放

音频采集数据->模拟信号->数模转换器ADC->二进制数据->渲染处理（音效调整/过滤）->音频数据压缩处理 编码

采样定律

奈奎斯特采样理论 中心思想： 当被采样的模拟信号被还原时，其最高频率只有采样频率的一半
人声音范围20—20kHz 选择的采样频率就应该在40kHz左右

音频文件格式

不压缩格式：PCM 数据 wav aiff后缀
无损压缩格式：FLAC m4a APE WV
有损压缩格式：mp3 aac

两种Linux平台下的音频驱动架构
OSS：早期
ALSA：取代OSS，主要文件节点， 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 系统的音频架构主要基于ALSA
现在 TinyALSA 只支持其中两种Interface 像 Raw MIDI Interface Sequencer Interface Timer Interface 则没有涉及

Android系统中的音频框架

Android音频系统

    从上到下依次是app层、java框架层(SoundPool\AudioTrack\AudioManager等)、本地框架层(framework/av)、硬件抽象层、驱动层

 
 

 
 
1

Java应用层 ：app
Audio的应用框架层：主要是一些java框架类 在framework/base下面
Audio本地框架层：包括AudioRecord.cpp AudioTrack.cpp等libmedia类，向上通过jni(有些称之为jni层)与应用框架层的java类相互调用，向下通过binder机制与audioflinger和audiopolicy等AudioServer进程或者MediaServer进行通信
Audio硬件抽象层：与上层通过AudioFlinger建立连接，向上服务于AudioFlinger，向下与硬件进行交互
Audio驱动程序层：ALSA

Audio驱动程序

驱动程序的框架有ALSA\OSS 等
包含两方面的功能： 控制接口：音量控制、静音、通道控制等
数据接口：需要支持PCM类型的输入输出
在有些系统中，还是和硬件解码结合在一起

硬件抽象层

Audio HAL: 音频的硬件抽象层, 服务的对象是AudioFlinger，是AudioFlinger和Audio硬件之间的层次

Audio HAL 层由主要以下接口组成：

/android_o/hardware/libhardware/include/hardware/audio.h
/android_o/hardware/libhardware/include/hardware/audio_effect.h

 
 

 
 
1
2

需要去实现这些接口

Audio HAL 提供了统一的接口定义它与AudioFlinger/AudioPolicyService之间的通信方式；
这就是 audio_hw_device, audio_stream_in, audio_stream_out等结构体。
由 audio.primary.和audio.a2dp.为名的各种库来填充，产品不同，音频设备存在很大的差异，在Android的音频架构中，这些差异是由HAL层的audio.primary等库解决的

Audio本地框架层

AudioFlinger

    AudioFlinger 把所有的(最多 32 个)AudioTrack 进行混音(Mixer)，然后输送 PCM 到 Audiohardware 中进行播放

 
 

 
 
1

上层Audio系统的核心由 AudioFlinger AudioPolicyService 和AudioTrack/AudioRecorder 三者构建而成。

其中 AudioFlinger AudioPolicyService 属于System Service，驻留在audioserver进程中，负责不断的处理AudioTrack/AudioRecorder的请求

Audio硬件抽象层以上的部分是Audio的公共部分，一般不会出现问题,更多的是一些客制化的需求；调试Audio的重点在硬件抽象层，在驱动程序有保证的情况下，首先需要调试通过数据流的输入输出逐一调试各种控制类的接口。

新的变化

Android 7.0以后本地框架层有了变化，从原来的MediaServer中分离出几个新的进程，如图所示：

Android O下Google将media部分的代码目录又进行了整理，从下面的目录看
新建了libaudioclient这个目录将AudioTrack、AudioEffect、AudioSystem.cpp、IAudioTrack.cpp、IAudioFlingerClient.cpp、ToneGenerator.cpp等放进去，在结构上与binder的C/S架构显得更加一致；

从Android4.1(jellybean) 开始Google从framework/base下的git库下将media的c/c++部分的多媒体框架单独设立framework/av的目录，给它开辟了一个Git库，到如今进一步的变化可见Google的煞费苦心以及多媒体部分的重要性。

当然多出来的不止libaudioclient，还有libaudiohal、libaaudio等，后续针对性的在研究下libaaudio

Audio 应用框架层

上层接口类型

AudioManager 是一个 java 类，是 android API 中 android.media.*的一部分。提供对音量和 ringer mode（包括铃声和振动）的设置。向下依赖于 AudioService 和 AudioSystem(java)。

AudioService 是一个 java 层系统服务，向底层转发所有用户发起的调用，同时负责监听 audio 动作的消息，如 audio 设备插入拔出，开关屏等。向下依赖于 AudioSystem(java)。

AudioSystem 由两部分组成，分别是 AudioSystem(java)和 AudioSystem(native)。
AudioSystem(java)提供管理 AudioSystem(native)的接口，只由 AudioService 内部调用，不对用 户开放。AudioSystem(native)提供对音频系统的控制，如音量、设备状态、forceUse 等。

AudioTrack 是 android API 中 android.media.*的一部分，提供用户从 java 层直接输出 PCM 数据和部分播放控制接口。AudioTrack 可以直接播放“音源为 PCM” 的音频数据。

AudioRecord：这个主要是用来录音的

AudioService是Android上层音频的核心服务，在SystemServer中启动，为所有音频相关设置提供服务。AudioManager和AudioService是通过Binder机制进行通信。AudioManager拥有AudioService的Bp端，是AudioService在客户端的一个代理。几乎所有的对AudioManager进行的请求，最终都会交给AudioService去处理。而AudioService的实现主要依赖于AudioSystem。AudioSystem是java层到native层的代理。

转载于安德路博主
https://blog.csdn.net/ch853199769/article/details/81781624