Android智能手机上的音频浅析及各种音频场景下的audio data path

最新推荐文章于 2024-01-12 16:08:03 发布

qianxuedegushi

最新推荐文章于 2024-01-12 16:08:03 发布

阅读量1.1k

点赞数 2

分类专栏： android audio

原文链接：https://www.cnblogs.com/talkaudiodev/p/8858470.html

版权

android audio 专栏收录该内容

36 篇文章 24 订阅

订阅专栏

转自：https://www.cnblogs.com/talkaudiodev/p/8733968.html

https://www.cnblogs.com/talkaudiodev/p/8858470.html

手机可以说是现在人日常生活中最离不开的电子设备了。它自诞生以来，从模拟的发展到数字的，从1G发展到目前的4G以及不久将来的5G，从最初的只有唯一的功能（打电话）发展到目前的全功能，从功能机（feature phone）发展到智能机（smart phone），可谓变化巨大。对于手机上的音频来说，刚开始只有语音通信功能，现在不仅语音通信，还可以听音乐、录音、智能语音（语音输入/语音交互）等。智能手机中的音频场景众多，可以说是手机多媒体系统中最复杂的子系统了。今天我们就谈谈Android智能手机上的音频。

先从硬件谈起吧。下图是android智能手机中目前主流的跟音频相关的硬件框图。

上图中AP是应用处理器（application processor），现在用的最多的是ARM的处理器，在上面主要运行的是操作系统（OS，例如android）和应用程序。CP是通信处理器（communication processor），也叫基带处理器（baseband processor，BP）或者modem，上面主要处理跟通信相关的，比如手机信号好不好就跟它相关。Audio DSP，顾名思义，就是一个处理音频的DSP。我在刚做手机的时候就很纳闷现在AP处理器频率那么高，音频处理（尤其是语音）CPU load 不高，AP上完全可以处理，为啥还要额外加一个音频DSP处理音频呢，这不是增加了成本吗？随着做的深入，知道了这主要是出于功耗的考虑。功耗是手机上的一个重要指标，也是过认证的必选项，它决定了手机的续航能力。在手机电池技术没有获得突破的现在，要想续航能力强，就得降功耗。音频中的打电话和听音乐是手机上的最主要功能之一，必须在这两种场景下降功耗。怎么降呢？就是加一块专门处理音频的DSP，在打电话和听音乐时让AP在绝大多数时间都出于sleep状态，这样功耗就降下来了。 AP、CP和audio DSP之间通过IPC（inter-processor communication）通信，交互控制消息和音频数据。通常AP、CP和audio DSP（当然还包括其他功能的处理器）集成在一个芯片内，形成一个SOC（system on chip，片上系统）。此外有一个主要用于音频采集和播放的硬件codec芯片，它受AP控制（使能以及选择不同音频路径等，主要是配置寄存器），与audio DSP通过I2S总线交换音频数据。连着硬件codec的是各种外设，有MIC（现在主流的是双MIC方案）、earpiece（听筒）、speaker（扬声器）、有线耳机（有三段式四段式两种，三段式没有MIC功能，四段式有）等。但是蓝牙耳机比较特殊，它是直接通过I2S总线与audio DSP连接的，主要是因为音频的采集和播放在蓝牙芯片里都有了。当用蓝牙耳机听音乐时，音频码流在AP上解码成PCM数据用A2DP协议经过UART直接送给蓝牙耳机播放，而不是经过audio DSP通过IIS总线送给蓝牙耳机播放。

再来看软件。音频相关的软件在三个处理器（AP/CP/audio DSP）上都有，先看AP上的音频软件。本文讲的是Android智能手机上的音频，运行的当然就是Android系统了，Android系统就运行在AP上。Android里有multimedia framework，audio是其中的一部分，AP上audio部分的软件框图如下：

Android音频软件分不同的层，主要有kernel/user/Framework/JNI/Java。从底层kernel向上讲吧。Android的核用的是Linux的。Linux上音频相关的子系统叫ALSA，包括kernel space和user space两部分。Kernel space里是音频驱动，user space里主要是提供API给应用程序调用。Android的音频驱动跟Linux是一样的，在user space里对ALSA进行了裁剪形成了tinyalsa。关于这些我在前面的文章（音频的采集和播放）里简单描述过，有兴趣可以去看看。同时user space里还有音频软件编解码的各种库，包括音乐的(MP3/AAC等)和语音的（AMR-NB/AMR-WB等）。再向上就是Framework，里面模块众多，主要有NuPlayer/stageFright Record/openMAX/AudioFlinger等，网上讲audio Framework的文章太多了，这里就不细讲了。Auido HAL(Hardware Adapter Layer,硬件适配层)也在这一层。Framework上层是JNI（Java Native Interface）,提供接口供Java调用，提供的接口主要有MediaRecorder/MediaPlayer/AudioTrack/AudioRecorder。最上层是Java层，也就是各种带有音频功能的APP（调用提供的API）了。

再看audio DSP上的音频软件。下图是audio的软件框图：

从上图看出，模块主要有codec（MP3/AAC/AMR/EVS等）、前处理（AGC/ANS/AGC等）、后处理（EQ/AGC/ANS 等）、重采样（SRC）、混音（MIX）、从DMA获取采集到的音频数据（CAPTURE）、将音频数据送给DMA后播放（PLAY）等，当然还有接收和发送给其他处理器的音频数据处理等，AP和CP都要与audio DSP交互语音数据。

最后看CP上的音频软件，它上面处理的就是跟语音通信相关的。2/3G跟4G完全处理完全不一样（2/3G是CS call，会有专用的信道处理语音。4G是一个纯IP的网络，是PS call），会有两套处理机制。我没做过CP上的音频处理（我主要做audio DSP上的音频处理，偶尔做些AP上的音频处理），对2/3G下的语音处理不熟悉，对4G下的语音处理了解。下图是4G下的音频软件处理框图：

主要分两大部分，IMS stub，处理IMS（IP Multimedia Subsystem, IP多媒体子系统）中的语音数据相关的（IMS 控制协议相关的在AP中处理）。Audio，对IMS中语音数据的pack/unpack以及与audio DSP的交互等。

智能手机中音频场景众多，有些场景中三个处理器中的音频软件都会涉及，比如打电话，AP上主要是处理一些控制上的逻辑，CP和audio DSP上不仅有控制逻辑，还有语音数据的处理，上行是先从MIC采集到语音经Audio DSP处理后变成码流发给CP，CP处理后经过空口发到网络上，下行是CP从空口拿语音码流，处理后发给audio DSP，audio DSP再解码后发给codec芯片直到外设播放出来。有些场景只涉及部分处理器中的音频软件，比如在播放音乐时CP上的音频软件就不会涉及，在用APP播放音乐时，是音乐从AP上传到audio DSP上，经过相关处理后通过外设播放出来。在下一篇文章中我会详细的描述在各种音频场景中音频数据的流向。

上一篇文章（Android智能手机上的音频浅析）说本篇将详细讲解Android智能手机中各种音频场景下的音频数据流向，现在我们就开始。智能手机中音频的主要场景有音频播放、音频录制、语音通信等。不同场景下的音频数据流向有很大差异，即使是同一场景，在不同的模式下音频数据流向也有所不同。

1，音频播放

Android系统audio框架中主要有三种播放模式：low latency playback、deep buffer playback和compressed offload playback。

a)low latency playback:用于按键音、游戏背景音等对时延要求高的声音输出。音频文件是在AP侧解码成PCM数据，然后再经由Audio DSP送给codec芯片播放出来。

b)deep buffer playback:用于音乐等对时延要求不高的声音输出。音频文件是在AP侧解码成PCM数据，如果有音效的话会再对PCM数据处理（android audio framework中有effect音效模块，支持的音效有均衡器、低音增强、环绕声等），然后再经由Audio DSP送给codec芯片播放出来。

c)compressed offload playback:用于音乐等声音输出，但是音频解码部分的工作是在Audio DSP中完成，AP侧只负责把音频码流送到Audo DSP中，送出去后AP侧会进行休眠，Audo DSP中会分配一块较大的buffer去处理此数据，在Audo DSP中进行解码、音效的处理等工作，在Audo DSP解码器处理完数据之前，它会唤醒AP侧去送下一包数据。用这种模式播放音频能有效的降低功耗，是最为推荐的播放音乐的模式。但是在目前的主流的音乐播放APP中用的基本上都是deep buffer的播放模式，比如QQ音乐、网易云音乐和酷狗音乐等。看来系统平台厂商和APP厂商的做法是有差异的。至于哪些格式的音乐用这种模式播放，这需要在audioPolicy中去控制，我做的平台上是MP3(*.mp3)和AAC(*.m4a)用offload模式播放，因为这两种格式最主流。

综上low latency 模式和deep buffer模式都是在AP侧解码完后送PCM数据给Audio DSP，故音频数据流向类似，我将放在一起讲，而compressed offload模式是码流送给Audio DSP解码。播放系统音和游戏音用low latency 模式，播放音乐用deep buffer或者compressed offload模式，播放录音用deep buffer模式。接下来我们看看low latency /deep buffer和compressed offload两种模式下的音频数据流向。在音频播放时音频数据只经过AP和audio DSP。

1）low latency / deep buffer模式下的音频数据流向

从上图看出，音频文件先在AP上软解码得到PCM后经过AudioTrack/audioFlinger中的Mixer thread(有可能要做音效后处理)/audio HAL/tinyALSA后送给kernel，然后用IPC将PCM送给Audio DSP经重采样混音等后播放出来。由于在AP上已做解码和音效后处理，Audio DSP上就不需要做了。

2）compressed offload模式下的音频数据流向

从上图看出，音频码流经过AP上的AudioTrack/audioFlinger中的Offload thread(不需要做音效后处理)/audio HAL/tinyALSA后送给kernel，然后用IPC将码流送给Audio DSP经解码、后处理、重采样、混音等后播放出来。

2，音频录制

很多人喜欢把参加的重要会议或者演讲的音频录下来，以便重复听或者他用。下图就是录音时音频数据的流向。同音频播放一样，录音时音频数据也是只经过AP和audio DSP。

从上图看出，codec芯片采集到的PCM数据送给Audio DSP经重采样、前处理后送给AP的kernel，再经由tinyALSA/audio HAL /audioFlinger中的Record thread/audioRecord等后做软编码得到录音码流文件并保持起来。

3，语音通信

语音通信就是打电话啦。它同音频播放或者录制不一样，它是双向的，分上行（uplink,把采集到的语音发送给对方）和下行(downlink，把收到的语音播放出来)，而音频播放或者录制是单向的。它音频数据流向也跟音频播放或者录制不一样，只经过audio DSP和CP，下图就是打电话时音频数据的流向。

从上图看出，在上行方向上codec芯片采集到的PCM数据送给Audio DSP经重采样、前处理(AEC/ANS/AGC等)、编码后得到码流，并将码流送给CP，CP处理后经过空口(air interface)送给对方。在下行方向上先从空口收对方送过来的语音数据，并做网络侧处理(jitter buffer等)，然后送给Audio DSP，Audio DSP收到后做解码、后处理(ANS/AGC等)、重采样等，再把PCM数据经DMA/I2S送给codec芯片播放出来。