AZURE

当遇到声音卡顿时，一般是遭遇xrun了，调试的时候可以通过alsa提供的xrun_debug接口来获取更多有用的信息，帮助定位问题。原文：http://www.alsa-project.org/main/index.php/XRUN_DebugThis page describes the build-in ALSA driver tool to debug PCM ring

这两天在查一个bug，结果bug没有完美解决，关于stream domain和stream event的触发过程倒是跟了个遍。记于此，也好慰告《DAPM之四：dapm widget events》大坑的在天之灵。另外，以前的DAPM系列均基于Linux-2.6.32来分析的，目前我们使用Linux-3.4.5，dapm改动很大了。列举一点：Linux-2.6.32时代，无论codec处在什

1、问题应该发生在：int snd_soc_suspend(struct device *dev){ //... for (i = 0; i num_rtd; i++) { struct snd_soc_dai *codec_dai = card->rtd[i].codec_dai; if (card->rtd[i].dai_link->ignore_suspend)

ALSA: Advanced Linux Sound Architecture，它包括内核驱动集合、API库和工具。用户层程序直接调用libsound的API库，不需要打开设备等操作，因此编程者不需要了解底层细节。这里不分析ALSA的核心代码core，也不阐述如何在用户层进行声卡编程，仅仅简要介绍在ALSA的架构上添加一个声卡驱动，即上图中的Sound Driver。其实文档《wirte an

Linux kernel version：3.4.5SoC：Samsung exynosUserspace：tinyalsa音频驱动主要有三个domain组成：1、 Platform：通常指某款SoC平台，如exynos、omap等等。Platform又可细分两部分：1.1、CPU DAI：在嵌入式系统里面通常指CPU的I2S、PCM总线接口，负责将音频数据从I2S F

ASoC：ALSA System on Chip，是建立在标准ALSA驱动之上，为了更好支持嵌入式系统和移动设备中的音频codec的一套软件体系，它依赖于标准ALSA驱动框架。内核文档alsa/soc/overview.txt中详细介绍了ASoC的设计初衷，这里不一一引用，简单陈述如下：·          独立的codec驱动，标准的ALSA驱动框架里面codec驱动往往与SoC CPU耦合

本章开始时提到codec_drv的几个组成部分，下面逐一介绍，基本是以内核文档Documentation/sound/alsa/soc/codec.txt中的内容为脉络来分析的。Codec DAI和PCM的配置信息codec_dai和pcm配置信息通过结构体snd_soc_dai_driver描述，包括dai的能力描述和操作接口，snd_soc_dai_driver最终会被注册

后面章节将分析 dma buffer 的管理，其中细节需要对音频数据相关概念有一定的了解。因此本章说明下音频数据中的几个重要概念：Sample：样本长度，音频数据最基本的单位，常见的有 8 位和 16 位；Channel：声道数，分为单声道 mono 和立体声 stereo；Frame：帧，构成一个完整的声音单元，Frame = Sample * channel；Rate：又称 sample

前面几章分析了Codec、Platform、Machine驱动的组成部分及其注册过程，这三者都是物理设备相关的，大家应该对音频物理链路有了一定的认知。接着分析音频驱动的中间层，由于这些并不是真正的物理设备，故我们称之为逻辑设备。PCM逻辑设备，我们又习惯称之为PCM中间层或pcm native，起着承上启下的作用：往上是与用户态接口的交互，实现音频数据在用户态和内核态之间的拷贝；往下是触发co

章节ASoC中的codec_drv和ASoC中的platform_drv介绍了codec、platform（I2S、pcm_dma）驱动，但仅有codec、platform驱动是不能工作的，需要一个角色把codec、codec dai、cpudai、pcm dma给链结起来才能组成一个完整的音频回路，这个角色就由machine_drv承担了。struct snd_soc_dai_lin

概述中提到音频Platform驱动主要作用是音频数据的传输，这里又细分为两步：·          把音频数据从userspace通过dma或者mmap方式搬运到cpu_dai FIFO，这部分驱动用snd_soc_dai_driver描述，后面分析用pcm dma指代它。·          把音频数据从cpu_dai FIFO通过数字音频接口（I2S/PCM/AC97）传送到codec

前些日子写了一篇snd_kcontrol探究，该文主要从内核源码出发简单讲述一下kcontrol接口的始末。这几天因为要在Android里面添加一些音频控制接口，配合alsa_amixer scontents分析，对此有了更深的体会，记录于此。因为这方面的资料实在太少，很多东西都是自我理解的，如有错误请见谅并指出。name字段是名称标识，这个字段非常重要，因为kcontrol的作用由名称来区分，对于名称相同的kcontrol，则使用index区分。name定义的标准是“SOURCE DIRECTION

control控制接口控制接口对于许多开关(switch)和调节器(slider)应用广泛，它能被用户空间存取，从而读写CODEC相关寄存器。control的主要用于mixer。它用snd_kcontrol_new结构体描述。snd_kcontrol_newstruct snd_kcontrol_new { snd_ctl_elem_ifac

2012已经到来，无论这个世界是否行将毁灭，在那之前的日子还得要继续。Android迈进了4.0，相应的Linux内核也进入了3.x时代。之后的一个工作估计要将2.6.32的驱动移植到3.x上面来。因此趁现在有空，看看alsa在这方面有什么改动。总的来说，架构大的改动是不大可能的。codec中几个关键结构体没有大的变化，如snd_soc_dai_ops、snd_soc_dai_dr

这段时间在探索ALSA架构，从ALSA Core到ALSA Lib，再到Android Audio System。在看ALSA Lib时，写了一个比较典型的基于ALSA的播放录音程序。程序包包含四个部分：WAV Parser是对WAV文件的分析和封装，这里只针对Standard WAV File；SND Common是Playback 和Record共同操作，如SetParams、Read

之前写过一个音频驱动CODEC分析，当时忽略了阐述最基本的概念。要了解一个东西，首先要明白它是什么它起到什么作用，然后才会更好对它的工作流程更好的分析。所以这里提一下：CODEC ：音频芯片的控制，比如静音、打开（关闭）ADC（DAC）、设置ADC（DAC）的增益、耳机模式的

[Loong]：之前写过基于ALSA的WAV播放录音程序，见http://blog.csdn.net/sepnic/archive/2011/01/14/6140824.aspx。现在本想好好整理一下ALSA的编程思想，但Google了一下，发现已经有同道做了类似的工作，故将其转载过来，并添加一些本人的疑问以及补充（将会继续补充，原文很多重要的ALSA参数没有提到）。原文：http://blo

数码音频系统是通过将声波波形转换成一连串的二进制数据来再现原始声音的，实现这个步骤使用的设备是模/数转换器（A/D）它以每秒上万次的速率对声波进行采样，每一次采样都记录下了原始模拟声波在某一时刻的状态，称之为样本。将一串的样本连接起来，就可以描述一段声波了，把每一秒钟所采样的数目称为采样频率或采率，单位为HZ（赫兹）。采样频率越高所能描述的声波频率就越高。采样率决定声音频率的范围（相当于音调），可

DAPM--Dynamic Audio Power Management，对应结构体是snd_soc_dapm_widget和snd_soc_dapm_route，对应的操作函数是snd_soc_dapm_new_controls()、snd_soc_dapm_add_routes()和snd_soc_dapm_new_widgets()。在我看来，DAPM是音频驱动初接触者的噩梦。从何处来，到何处去？它字面上的意义是音频电源动态管理，但是往往困惑于它是怎么被触发的？而最郁闷的是：这方面的资料是最少的，我涉

在用alsa_amixer controls时，除了我们之前提到的snd_soc_add_controls添加的kcontrols外，还有一些多出来的controls。其实多出来的那些都是属于dapm kcontrol，主要用于切换音频路径。一、AUDIO PATHS OVERVIEW以标准内核2.6.32的wm9713 codec为例。先看AUDIO PATHS OVERVIEW，红色线路是LINPUT1(Left Input) -> LEFT INPUT PGA -> LEFT INPUT MI

其实asound.conf真跟dapm没多大关系，之所以把它也纳入dapm系列之一，是为了考虑到知识的连贯性。在提到：通过配置好asound.conf，上层则可打开asound.conf中定义的虚拟设备，而自动选择相应的音频通道。这是asound.conf很重要的一个作用，从这方面来说，并不是跟dapm完全没关系。

需求：USB Headset插上去后，声音要从本地CODEC切换到USB Headset输出/输入。上网搜了有关USB Audio Hotplug的东西，比较适用的资源如下：1、Hotplugging USB audio devices (Howto)题目看起

这一年来的一个重要工作是音频设备驱动方面，如驱动开发、调试debug、性能调优、音频路由、回声消除等。除此之外，熟悉了一下alsa-lib接口，Android音频系统，包括设备抽象层和音频策略。遗憾的是一直没有什么机会接触蓝牙设备的集成和开发，可预知的未来无线设备会极大地普及。还有就是ffmpeg，以前经常用它来做一些兴致突来能力而及的小工具，年初时计划进一步在它的基础上学习H264或

hwdep模块简述字符设备驱动中，ioctl是一个很常见的IO设备操作函数，可以自定义cmd命令字并实现对应的设备IO控制。音频设备的控制有所不同：驱动层大部分控制操作定义各种snd_kcontrol_new，然后注册到SNDRV_DEV_CONTROL模块中（sound\core\control.c），详见snd_kcontrol探究；而上层调用alsa-lib的snd_ctl_

经过一周多的整理，包括一个周末，终于形成这个较为条理的文档。dapm系列从开坑到现在，时间跨度是3个多月。呵呵，这其实比我想象中要快，毕竟平时工作还是挺忙的。今后我想关于音频驱动方面的内容会减少，并不是说我已经全部掌握了alsa架构，pcm、card方面都没有进入深入研究。

dapm触发时的入口函数是dapm_power_widgets，稍后详细分析这个函数，这里仅说其作用：检查每个dapm widget，如果该widget处在一条complete paths中，则power up这个widget，否则power down。

哲学里有三个终极命题：你是谁？从何处来？到何处去？而对于dapm机制，我们可以这样提问：dapm是什么，起到何作用？dapm是如何建立的？dapm又是如何触发的？下面会就这三个问题进行分析。首先是dapm是什么？

这是一个坑。。。