Linux ALSA声卡驱动之五：移动设备中的ALSA（ASoC）

最新推荐文章于 2023-06-15 23:08:01 发布

GabbyZang

最新推荐文章于 2023-06-15 23:08:01 发布

阅读量840

点赞数

分类专栏： Q_AUDIO

Q_AUDIO 专栏收录该内容

21 篇文章 0 订阅

订阅专栏

http://blog.csdn.net/droidphone/article/details/7165482

1.  ASoC的由来ASoC--ALSA System on Chip ，是建立在标准ALSA驱动层上，为了更好地支持嵌入式处理器和移动设备中的音频Codec的一套软件体系。在ASoc出现之前，内核对于SoC中的音频已经有部分的支持，不过会有一些局限性：
   Codec驱动与SoC CPU的底层耦合过于紧密，这种不理想会导致代码的重复，例如，仅是wm8731的驱动，当时Linux中有分别针对4个平台的驱动代码。
   音频事件没有标准的方法来通知用户，例如耳机、麦克风的插拔和检测，这些事件在移动设备中是非常普通的，而且通常都需要特定于机器的代码进行重新对音频路劲进行配置。
  当进行播放或录音时，驱动会让整个codec处于上电状态，这对于PC没问题，但对于移动设备来说，这意味着浪费大量的电量。同时也不支持通过改变过取样频率和偏置电流来达到省电的目的。
ASoC正是为了解决上述种种问题而提出的，目前已经被整合至内核的代码树中：sound/soc。ASoC不能单独存在，他只是建立在标准ALSA驱动上的一个它必须和标准的ALSA驱动框架相结合才能工作。
 /********************************************************************************************/ 
  
 声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！ 
  
 /********************************************************************************************/ 
  

2.  硬件架构通常，就像软件领域里的抽象和重用一样，嵌入式设备的音频系统可以被划分为板载硬件（Machine）、Soc（Platform）、Codec三大部分，如下图所示：
                                        图2.1  音频系统结构
Machine  是指某一款机器，可以是某款设备，某款开发板，又或者是某款智能手机，由此可以看出Machine几乎是不可重用的，每个Machine上的硬件实现可能都不一样，CPU不一样，Codec不一样，音频的输入、输出设备也不一样，Machine为CPU、Codec、输入输出设备提供了一个载体。
Platform  一般是指某一个SoC平台，比如pxaxxx,s3cxxxx,omapxxx等等，与音频相关的通常包含该SoC中的时钟、DMA、I2S、PCM等等，只要指定了SoC，那么我们可以认为它会有一个对应的Platform，它只与SoC相关，与Machine无关，这样我们就可以把Platform抽象出来，使得同一款SoC不用做任何的改动，就可以用在不同的Machine中。实际上，把Platform认为是某个SoC更好理解。
Codec  字面上的意思就是编解码器，Codec里面包含了I2S接口、D/A、A/D、Mixer、PA（功放），通常包含多种输入（Mic、Line-in、I2S、PCM）和多个输出（耳机、喇叭、听筒，Line-out），Codec和Platform一样，是可重用的部件，同一个Codec可以被不同的Machine使用。嵌入式Codec通常通过I2C对内部的寄存器进行控制。 
3.  软件架构在软件层面，ASoC也把嵌入式设备的音频系统同样分为3大部分，Machine，Platform和Codec。
Codec驱动  ASoC中的一个重要设计原则就是要求Codec驱动是平台无关的，它包含了一些音频的控件（Controls），音频接口，DAMP（动态音频电源管理）的定义和某些Codec IO功能。为了保证硬件无关性，任何特定于平台和机器的代码都要移到Platform和Machine驱动中。所有的Codec驱动都要提供以下特性： 
    Codec DAI 和 PCM的配置信息；
Codec的IO控制方式（I2C，SPI等）；
Mixer和其他的音频控件；
Codec的ALSA音频操作接口；
 
必要时，也可以提供以下功能：
DAPM描述信息；
DAPM事件处理程序；
DAC数字静音控制
 
  
Platform驱动  它包含了该SoC平台的音频DMA和音频接口的配置和控制（I2S，PCM，AC97等等）；它也不能包含任何与板子或机器相关的代码。
Machine驱动  Machine驱动负责处理机器特有的一些控件和音频事件（例如，当播放音频时，需要先行打开一个放大器）；单独的Platform和Codec驱动是不能工作的，它必须由Machine驱动把它们结合在一起才能完成整个设备的音频处理工作。
4.  数据结构整个ASoC是由一些列数据结构组成，要搞清楚ASoC的工作机理，必须要理解这一系列数据结构之间的关系和作用，下面的关系图展示了ASoC中重要的数据结构之间的关联方式：

 
                                                                                                      图4.1  Kernel-2.6.35-ASoC中各个结构的静态关系
 ASoC把声卡实现为一个Platform Device，然后利用Platform_device结构中的dev字段：dev.drvdata，它实际上指向一个snd_soc_device结构。可以认为snd_soc_device是整个ASoC数据结构的根本，由他开始，引出一系列的数据结构用于表述音频的各种特性和功能。snd_soc_device结构引出了snd_soc_card和soc_codec_device两个结构，然后snd_soc_card又引出了snd_soc_platform、snd_soc_dai_link和snd_soc_codec结构。如上所述，ASoC被划分为Machine、Platform和Codec三大部分，如果从这些数据结构看来，snd_codec_device和snd_soc_card代表着Machine驱动，snd_soc_platform则代表着Platform驱动，snd_soc_codec和soc_codec_device则代表了Codec驱动，而snd_soc_dai_link则负责连接Platform和Codec。
5.  3.0版内核对ASoC的改进本来写这篇文章的时候参考的内核版本是2.6.35，不过有CSDN的朋友提出在内核版本3.0版本中，ASoC做了较大的变化。故特意下载了3.0的代码，发现确实有所变化，下面先贴出数据结构的静态关系图：

 
                                                                                             图5.1   Kernel 3.0中的ASoC数据结构
由上图我们可以看出，3.0中的数据结构更为合理和清晰，取消了snd_soc_device结构，直接用snd_soc_card取代了它，并且强化了snd_soc_pcm_runtime的作用，同时还增加了另外两个数据结构snd_soc_codec_driver和snd_soc_platform_driver，用于明确代表Codec驱动和Platform驱动。
 
后续的章节中将会逐一介绍Machine和Platform以及Codec驱动的工作细节和关联。
 
  分享到：  
   
   
 
 
  上一篇：翻译：Linux的电源管理架构
下一篇：Linux ALSA声卡驱动之六：ASoC架构中的Machine

查看评论

 
    3楼  
   zcf19871112 2012-09-20 10:14发表 [回复] 
   
    分析得很好，楼主，您画UML图用的是什么软件？ 
   
    2楼  
   wantianpei 2012-07-27 15:05发表 [回复] [引用] [举报] 
   
    楼主：我的理解是这样的，不知道是否有问题？请指教。 
   
 Codec：相当于解码，编码纯软件的代码，都可重复利用。 
   
 Platform：i2s,pcm……芯片级硬件控制接口相关代码，同一种soc芯 片可以重复利用。 
   
 Machine：把platform驱动和codec驱动绑定在一起，并实现一些附加操作，比如说音乐播放时给功放机上电，播放完后功放关电。这部分跟机器电路相关，所以一般不能重复利用。 
   
 是这样的吗？ 
   
 我对machine部分还是不太理解，它还有别的作用吗？能详细描述下吗？多谢！ 
   
    1楼  
   liuyan4043 2012-02-01 16:42发表 [回复] 
   
    持续关注中，期待下一篇！