邯郸做网站推广百度关键词优化大

Linux音频框架参考文章：Linux音频框架

机器声音的采集原理

声音是一种连续的信号，故其是一种模拟量。
录音设备可以捕获声音这种连续的信号，转化成相应的模拟量。
我们若要存储下声音，就要保存这些模拟量，但是通常我们会把这些模拟量转化成离散的数字信号，然后再保存下来。

模拟量转化成数字量的过程有个专业的名称：ADC（analog convert to digital）
百度上，ADC是模拟数字转换器（英语：Analog-to-digital converter）

机器声音的播放原理

捕获的声音用离散的数字量表示后，若我们播放这些声音，那么我们需要把这些数字量转化为模拟量后，我们就能听到这些声音了。

这个过程就是CDA，数字信号转模拟信号。

音频相关基本概念

在大致了解音频的采集和播放的原理后，这里了解一下音频相关的参数含义以及一些基本概念。

• 样本长度(sample)：
  一次采样得到的数据叫做样本，样本是记录音频数据最基本的单位，其长度常见的有8位，16位，24位，32位。
  如下图，下面使用4位的样本长度来记录声音的波形。可以推测得到，若样本长度越大，采集的声音波形也准确。
  

• 通道数(channel)：
  就是声道数，该参数为1表示单声道，2则是立体声。

• 桢(frame)：
  桢记录了一个声音单元，其长度为样本长度与通道数的乘积。
  譬如对于样本长度为16bit的双声道来说，一帧的大小等于：16 * 2 / 8 = 4个字节。

• 采样率(rate)：
  每秒钟采样的次数，该次数是针对桢而言。

• 周期(period)：
  音频设备一次处理所需要的桢数，对于音频设备的数据访问以及音频数据的存储，都是以此为单位。
  譬如周期的大小为1024帧，则表示音频设备进行一次读或写操作的数据量大小为1024帧，假设一帧为4个字节，那么也就是1024*4=4096个字节数据。
  一个周期其实就是两次硬件中断之间的帧数，音频设备每处理（读或写）完一个周期的数据就会产生一个中断，所以两个中断之间相差一个周期

• 交错模式(interleaved)：
  是一种音频数据的记录方式，在交错模式下，数据以连续桢的形式存放，即首先记录完桢1的左声道样本和右声道样本（假设为立体声格式），再开始桢2的记录。而在非交错模式下，首先记录的是一个周期内所有桢的左声道样本，再记录右声道样本，数据是以连续通道的方式存储。不过多数情况下，我们只需要使用交错模式就可以了。

• 缓冲区（buffer）
  数据缓冲区，一个缓冲区包含若干个周期，所以buffer是由若干个周期所组成的一块空间。下面一张图直观地表示了buffer、period、frame、sample（样本长度）之间的关系，假设一个buffer包含4个周期、而一个周包含1024帧、一帧包含两个样本（左、右两个声道）
  

计算机采集音频的模型

音频采集主要有三者：①音频输出及捕获设备，②codec编解码设备，③MCU带音频数据接口的单片机。如下图所示。

①音频输出及捕获设备：扬声器、麦克风
扬声器负责根据输入的模拟量数据播放声音。
麦克风负责把声音转化成模拟量并输出。

②MCU：带音频数据接口的片上系统芯片(SOC)
platform可以理解成 带有 音频数据传输接口的 单片机。
platform可以输入和输出音频数字信号。

③codec：数字信号模拟信号编解码器
codec有以下两个功能：
1.把platform通过音频数据传输接口输出的数字信号转化成模拟信号，传输给扬声器。
2.把麦克风的模拟信号转化成数字信号，通过音频数据传输接口传输给platform

Linux系统音频框架

Linux中使用的音频框架是ASOC(ALSA System on Chip)

ASOC的出现就是为了解决ALSA无法解决的问题。ALSA到底存在什么问题？ 以及ASOC会以怎样的方式去解决ALSA存在的问题？

详细参考内核文档: kernel\documentation\sound\alsa\soc\Overview.txt

ALSA存在的问题：

1. Codec驱动与SOC中断CPU耦合严重，这将导致代码重复，一个Codec驱动每个cpu上会出现不同的版本。

2. 当音频事件发生时(插拔耳机，音箱)没有标准的方法通知用户，尤其在移动端此事件非常常见。

3. 当播放/录制音频时，驱动会让整个codec处于上电状态，这样会在移动端非常浪费电量。同时也不支持改变采样频率/配置电流来节约功耗。

针对以上问题，提出了ASOC(ALSA System on Chip)来力争解决上述问题。解决方法如下：

1. Codec代码独立，不再耦合与CPU，这样可以增加Codec代码重复利用。

2. 在Codec和Soc之间通过简单的I2S/PCM音频接口通信，这样SOC和Codec只需要注册自己相关的接口到ASOC code即可。

3. 动态的电源管理(Dynamic Audio Power Management)DAPM。DAPM始终将Codec自动设置在最低功耗状态运行。

4. 消除pop音。控制各个widget上下电的顺序消除pop音。

5. 添加平台相关的控制，运行平台添加控制设备到声卡。

Linux音频框架的三类角色

ASOC音频架构为了实现上述的新feature，ASOC将嵌入式音频系统分为三大类可重复使用的驱动程序: Platform, Machine, Codec。

Codec类: Codec即编解码芯片的驱动，此Codec驱动是和平台无关，包含的功能有: 音频的控制接口，音频读写IO接口，以及DAPM的定义等。如果需要的话，此Codec类可以在BT，FM，MODEM模块中不做修改的使用。因此Codec就是一个可重复使用的模块，同一个Codec在不同的SOC中可以使用。

Platform类: 可以理解为某款SOC平台，平台驱动中包括音频DMA引擎驱动，数字接口驱动(I2S, AC97, PCM)以及该平台相关的任何音频DSP驱动。同样此Platform也可以重用，在不同的Machine中可以直接重复使用。

Machine类: Machine可以理解为是一个桥梁，用于在Codec和Platform之间建立联系。此Machine指定了该机器使用那个Platform，那个Codec，最终会通过Machine建立两者之间的联系。

在软件上可以抽象如下图：

ASOC数据结构
在分析整个ASOC的过程中，出现了众多的数据结构，在此先理清重要的数据结构的关系。如下图：

可以看到Machine是连接Codec和Platform之间的桥梁，因此首先要分析Machine部分，在下节分析Machine部分。