音频的采集和播放

Posted 2020-10-02 谈谈音频开发

音频的采集和播放主要由专门的codec芯片完成，主流的codec芯片厂商有Circus Logic、Wolfson等。采集时codec芯片通过A/D采样把声音的模拟信号转换成数字信号并通过I2S总线送给CPU处理，播放时CPU把处理好的数字信号通过I2S总线送给codec芯片并通过D/A转换为模拟信号播放出来。codec芯片除了A/D, D/A功能外还有其他功能，主要有1）对音频通路进行控制，比如播放音乐打电话等在codec芯片内部的流通线路是不一样的。2）对音频信号做相应的处理，比如音量控制、功率放大、EQ控制等。

音频的采集和播放在软件上主要是写音频的驱动程序，同时提供接口给上层调用。我主要用过linux和android，而这两大系统又是嵌入式和手机上的主流系统，android又是基于linux的。本文主要讲这两大系统上的音频采集和播放软件开发。

1，linux

Linux中跟音频相关的就是大名鼎鼎的ALSA(Advanced Linux Sound Architecture)了。它是linux上的音频子系统，在kernel space和user space都有相应的代码。kernel space里主要是音频的驱动程序，user space里主要是alsa-lib,也就是提供接口给上层应用程序调用。 User space 和kernel space通过字符设备进行交互。

在kernel space里ALSA相关的叫ASOC(ALSA System On Chip), 它有三大模块组成：板载硬件（Machine）、Soc（Platform）、Codec，如下图所示：

                                                            

Machine是指某一款具体的产品，由此可以看出Machine几乎是不可重用的，每个Machine上的硬件实现可能都不一样，CPU不一样，Codec不一样，音频的输入、输出设备也不一样，Machine为CPU、Codec、输入输出设备提供了一个载体。Platform一般是指某一个SoC平台，只要指定了SoC，那么我们可以认为它会有一个对应的Platform，它只与SoC相关，与Machine无关，这样我们就可以把Platform抽象出来，使得同一款SoC不用做任何的改动，就可以用在不同的Machine中。Codec和Platform一样，是可重用的部件，同一个Codec可以被不同的Machine使用。

这三个模块都有相应的driver. Platform driver是cpu侧的音频驱动，主要由CPU芯片厂商负责编写，主要作用是完成音频数据的管理，通过CPU的数字音频接口（DAI）把音频数据传送给Codec进行处理，最终由Codec输出驱动耳机或者是喇叭的音信信号。在具体实现上，ASoC把Platform驱动分为两个部分：snd_soc_platform_driver和snd_soc_dai_driver。其中，platform_driver负责管理音频数据，把音频数据通过dma或其他操作传送至cpu dai中，dai_driver则主要完成cpu一侧的dai的参数配置，同时也会通过一定的途径把必要的dma等参数与snd_soc_platform_driver进行交互。

codec driver是codec芯片侧的音频驱动，主要由codec芯片厂商负责编写，主要作用在上面已说过。ASoC中的一个重要设计原则就是要求Codec驱动是平台无关的，它包含了一些音频的控件（Controls），音频接口，DAMP（动态音频电源管理）的定义和某些Codec IO功能。同platform driver一样，codec driver也分为两个部分：snd_soc_codec_driver和snd_soc_dai_driver,作用也同platform driver类似。

Machine driver主要是做产品的厂商编写（产品厂商会购买codec芯片CPU芯片做成一个能用的产品）。Machine驱动负责Platform和Codec之间的耦合以及部分和设备或板子特定的代码。

ALSA 在User space里以ALSA-Lib存在，即提供API给应用程序调用。应用时主要有两种模式：block & nonblock，可以根据应用场景选择合适的模式。

ALSA是个庞大复杂的子系统，网上关于ALSA的内容特别多，包括kernel space和user space的，这里就不多叙述了。

2，Android

Android是基于linux的，即用的是linux的核，所以在音频驱动部分跟linux是一样的。不同的是在user space 部分不再用 ALSA-lib, 取而代之的是tinyalsa, 它是ALSA-Lib的裁剪。同时Android在Native层有media framework, 音频相关的模块有 AudioRecord/AudioTrack/AudioFlinger等，它们有层次关系，从上往下调用最终会调用tinyalsa的API跟kernel交互。

如果从事的是音频类的APP开发，kernel以及media framework都是不可见的，他们可以调用JAVA层提供的API实现音频功能，但这样会存在JAVA层和Native层之间的音频数据拷贝，效率较低，尤其是在实时通信类APP中。建议使用 Android NDK 提供的 OpenSL ES API 接口，它支持在 native 层直接处理音频数据。OpenSL ES 调用Native层media framework中的AudioRecord/AudioTrack, 从而实现音频数据的采集和播放，这样音频数据就不会到JAVA层了，效率较高。JAVA层跟Native层主要通过JNI实现一些控制功能。