/*****************************************************************************************************************/
声明: 本博客内容均由https://blog.csdn.net/weixin_47702410原创，转载or引用请注明出处，谢谢!
创作不易，如果文章对你有帮助，麻烦点赞 收藏支持~感谢
/*****************************************************************************************************************/
一、什么是ASOC以及ASOC解决的三个问题
在没有推出音频框架之前，我们一般用字符型设备驱动来定义设备上的音频设备。但是随着使用场景的多样化和复杂化，用字符型设备驱动模型来定义音频设备出现了很大的局限性，例如：
- 问题1：编解码器驱动程序通常与底层 SoC CPU 紧密耦合。例如音频有关产品需要音频外设厂商与CPU/SOC厂商紧密合作来完成音频设备驱动
- 问题2：用户与硬件交互麻烦，例如需要调节喇叭音量则可能要完成相关的驱动程序或者向用户提供API接口，故不同厂商的实现方式都有很大区别
- 问题3：耗电量高，通过通过节点就直接打开了音频外设（上电），没有尽可能的减少耗电量
如此，音频ASoC（ALSA System on Chip）便诞生了（中间还有用OSS，但后续已经逐渐被ASOC取代了）！ASOC是Linux内核中的一个音频子系统，专门为嵌入式系统上的SoC（System on Chip）音频接口设计。ASoC提供了一种高度模块化和可扩展的方式来处理SoC音频功能。
请注意：
1、ASOC是ALSA的一部分，它们之间是包含关系，ALSA包括了ASOC在内所有代码
2、ASOC侧重于与硬件交互的部分，更加偏向底层；ALSA Framework侧重于应用层，主要侧重Linux user层与Kernel层的交互。
二、ASOC的组成与功能
Linux官方描述：
ASoC 层旨在解决这些问题并提供以下功能：-
1.编解码器独立性。允许在其他平台和机器上重用编解码器驱动程序。
2.编解码器和 SoC 之间的简单 I2S/PCM 音频接口设置。每个 SoC 接口和编解码器都会向内核注册其音频接口功能，并在已知应用硬件参数时进行匹配和配置。
3.动态音频电源管理 (DAPM)。DAPM 始终自动将编解码器设置为最低功耗状态。这包括根据内部编解码器音频路由和任何活动流来打开/关闭内部电源模块。
4.减少爆音和咔嗒声。通过以正确的顺序打开/关闭编解码器电源（包括使用数字静音），可以减少爆裂声和咔嗒声。ASoC 向编解码器发出何时更改电源状态的信号。
5.机器特定控制：允许机器向声卡添加控制（例如扬声器放大器的音量控制）。
为了实现这一切，ASoC 基本上将嵌入式音频系统拆分为多个可重复使用的组件驱动程序：-
1.Codec class drivers：codec class driver与平台无关，包含音频控件、音频接口功能、编解码器 DAPM 定义和编解码器 IO 函数。如果需要，此类可扩展到 BT、FM 和 MODEM IC。codec class driver应该是可以在任何体系结构和机器上运行的通用代码。
2.Platform class drivers：平台类驱动程序包括音频 DMA 引擎驱动程序、数字音频接口 (DAI) 驱动程序（例如 I2S、AC97、PCM）以及该平台的任何音频 DSP 驱动程序。
3.Machine class driver：机器驱动程序类充当粘合剂，描述并将其他组件驱动程序绑定在一起以形成 ALSA“声卡设备”。它处理任何机器特定的控制和机器级音频事件（例如在播放开始时打开放大器）。
Linux官方描述还是非常准确和专业的，给它点个赞！
我这边解释一下，
ASOC可以分为三大块，如下图：
先说一下芯片控制音频外设的基本操作方法：
CPU通过内部总线控制片内外设（I2S、PCM等等），然后片内外设再去控制音频外设，其中片内外设会根据音频外设厂商给出的方法按照一定的顺序去读取或者发送相关音频数据。
理解一下这三大块：
- Codec：指的是音频编解码IC的代码，这部分代码通常就是音频编解码厂商需要提供，这部分代码会告知片内外设要以何种时序去读取或者发送数据。
- Platform：指的是平台端的代码，也就是CPU端和片内外设的初始化
- Machine：指的是中间层，会连接codec和machine。例如设备支持多个Codec，你现在想用某个codec就在这里指定。或者你有一个codec，想在某个平台用，也在machine中指定。
解决第一个问题
根据上图的ASOC宽假，我们便可以解决了第一个问题（问题1：编解码器驱动程序通常与底层 SoC CPU 紧密耦合）。在这种逻辑下：
CPU/SOC厂商就只关注platform的代码
外设音频编解码器厂商只关注codec代码
生产厂商就只关注Machine层，将某个CPU/SOC 与 音频外设连接便可。
但是通常情况下，这三部分人员都需要互相懂对方，以方便大家沟通。
解决第二个问题
ASOC提供了如下的测量解决第二个问题（用户与硬件交互麻烦）：
机器特定控制：允许机器向声卡添加控制（例如扬声器放大器的音量控制）。
描述一下，ASOC主要提供了一种方法供使用者选择，这种方法是ASOC Common的，如果使用这种方法，那么就会让用户更加便捷控制，并且由于是ALSA提供的，其安全性和可靠性更加优秀。
此处，ASoC提供了一套标准化的控制接口指的是kcontrols，这些控制接口允许用户空间的应用程序通过标准的ALSA控制接口与音频硬件进行交互。这些控制接口可以用来调节音量、切换音频路径、控制音效等。
解决第三个问题
ASOC提供了下面的方法来解决第三个问题（耗电量高）：
3.动态音频电源管理 (DAPM)。DAPM 始终自动将编解码器设置为最低功耗状态。这包括根据内部编解码器音频路由和任何活动流来打开/关闭内部电源模块。
Linux官方说的是一个总结性的内容，具体来讲它省电的方法在于：
当打开节点的时候，音频的设备不一定会上电，并且当你设置kcontrols给音频硬件上电的时候，硬件也不一定上电了。设备要有数据传输(有数据传输便意味着硬件已经打开，由先open后write/read的软件流程决定)且kcontrols设置上电才会真正的去给硬件上电。
如此便可以解决上电但没有使用造成的电量空损耗的问题了。
三、ASOC基本工作原理
其基本的原理是：
在ASOC框架下，
主控IC厂商将其IC特有的操作封装成一系列的标准ASOC接口函数提供给ASOC；
而编解码厂商则会在codec侧将其音频IC的特定操作封装成一系列的标准ASOC接口函数提供给ASOC。
产品厂商在machine层会整合主控IC和编解码IC的内容。
最后在实际录音或者播放的时候，ASOC会按照一定的顺序去调用这两组ops，例如执行open的时候，就会先去调用Platform层的ops去初始化CPU侧的环境，为codec的使用提供环境，再去调用codec端的ops完成特定的外设的初始化。
下图展现其基本的原理：
文章来源：https://www.toymoban.com/news/detail-819949.html
指的注意的是codec的ops是不一定与platform的ops对应，其是两种ops，这两种ops会由ASOC统一去管理与调用，以完成指定的动作。文章来源地址https://www.toymoban.com/news/detail-819949.html
到了这里，关于【ASOC全解析（一）】ASOC架构简介和欲解决的问题的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
