Linux内核4.14版本——alsa框架分析(11)——DAPM(2)——widget、route和path的概念

目录

1. DAPM的基本单元:widget(struct  snd_soc_dapm_widget)

2. widget的种类

3. widget之间的连接器:path(struct snd_soc_dapm_path)

4. widget的连接关系:route(struct snd_soc_dapm_route)


      上一篇文章中,我们介绍了音频驱动中对基本控制单元的封装:kcontrol。利用kcontrol,我们可以完成对音频系统中的mixer,mux,音量控制,音效控制,以及各种开关量的控制,通过对各种kcontrol的控制,使得音频硬件能够按照我们预想的结果进行工作。同时我们可以看到,kcontrol还是有以下几点不足:

(1)只能描述自身,无法描述各个kcontrol之间的连接关系;
(2)没有相应的电源管理机制;
(3)没有相应的时间处理机制来响应播放、停止、上电、下电等音频事件;
(4)为了防止pop-pop声,需要用户程序关注各个kcontrol上电和下电的顺序;
(5)当一个音频路径不再有效时,不能自动关闭该路径上的所有的kcontrol;

      为此,DAPM框架正是为了要解决以上这些问题而诞生的,DAPM目前已经是ASoc中的重要组成部分,让我们先从DAPM的数据结构开始,了解它的设计思想和工作原理。

1. DAPM的基本单元:widget(struct  snd_soc_dapm_widget)

      文章的开头,我们说明了一下目前kcontrol的一些不足,而DAPM框架为了解决这些问题,引入了widget这一概念,所谓widget,其实可以理解为是kcontrol的进一步升级和封装,她同样是指音频系统中的某个部件,比如mixer,mux,输入输出引脚,电源供应器等等,甚至,我们可以定义虚拟的widget,例如playback stream widget。widget把kcontrol和动态电源管理进行了有机的结合,同时还具备音频路径的连结功能,一个widget可以与它相邻的widget有某种动态的连结关系。在DAPM框架中,widget用结构体snd_soc_dapm_widget来描述:

/* dapm widget */
struct snd_soc_dapm_widget {
	enum snd_soc_dapm_type id;
	const char *name;		/* widget name */
	const char *sname;	/* stream name */
	struct list_head list;
	struct snd_soc_dapm_context *dapm;

	void *priv;				/* widget specific data */
	struct regulator *regulator;		/* attached regulator */
	const struct snd_soc_pcm_stream *params; /* params for dai links */
	unsigned int num_params; /* number of params for dai links */
	unsigned int params_select; /* currently selected param for dai link */

	/* dapm control */
	int reg;				/* negative reg = no direct dapm */
	unsigned char shift;			/* bits to shift */
	unsigned int mask;			/* non-shifted mask */
	unsigned int on_val;			/* on state value */
	unsigned int off_val;			/* off state value */
	unsigned char power:1;			/* block power status */
	unsigned char active:1;			/* active stream on DAC, ADC's */
	unsigned char connected:1;		/* connected codec pin */
	unsigned char new:1;			/* cnew complete */
	unsigned char force:1;			/* force state */
	unsigned char ignore_suspend:1;         /* kept enabled over suspend */
	unsigned char new_power:1;		/* power from this run */
	unsigned char power_checked:1;		/* power checked this run */
	unsigned char is_supply:1;		/* Widget is a supply type widget */
	unsigned char is_ep:2;			/* Widget is a endpoint type widget */
	int subseq;				/* sort within widget type */

	int (*power_check)(struct snd_soc_dapm_widget *w);

	/* external events */
	unsigned short event_flags;		/* flags to specify event types */
	int (*event)(struct snd_soc_dapm_widget*, struct snd_kcontrol *, int);

	/* kcontrols that relate to this widget */
	int num_kcontrols;
	const struct snd_kcontrol_new *kcontrol_news;
	struct snd_kcontrol **kcontrols;
	struct snd_soc_dobj dobj;

	/* widget input and output edges */
	struct list_head edges[2];

	/* used during DAPM updates */
	struct list_head work_list;
	struct list_head power_list;
	struct list_head dirty;
	int endpoints[2];

	struct clk *clk;
};

       snd_soc_dapm_widget结构比较大,为了简洁一些,这里我没有列出该结构体的完整字段,不过不用担心,下面我会说明每个字段的意义:

id    该widget的类型值,比如snd_soc_dapm_output,snd_soc_dapm_mixer等等。

*name    该widget的名字

*sname    代表该widget所在stream的名字,比如对于snd_soc_dapm_dai_in类型的widget,会使用该字段。

*codec *platform    指向该widget所属的codec和platform。

list    所有注册到系统中的widget都会通过该list,链接到代表声卡的snd_soc_card结构的widgets链表头字段中。

*dapm    snd_soc_dapm_context结构指针,ASoc把系统划分为多个dapm域,每个widget属于某个dapm域,同一个域代表着同样的偏置电压供电策略,比如,同一个codec中的widget通常位于同一个dapm域,而平台上的widget可能又会位于另外一个platform域中。

*priv    有些widget可能需要一些专有的数据,可以使用该字段来保存,像snd_soc_dapm_dai_in类型的widget,会使用该字段来记住与之相关联的snd_soc_dai结构指针。

*regulator    对于snd_soc_dapm_regulator_supply类型的widget,该字段指向与之相关的regulator结构指针。

*params    目前对于snd_soc_dapm_dai_link类型的widget,指向该dai的配置信息的snd_soc_pcm_stream结构。

reg shift mask     这3个字段用来控制该widget的电源状态,分别对应控制信息所在的寄存器地址,位移值和屏蔽值。

value  on_val  off_val    电源状态的当前只,开启时和关闭时所对应的值。

power invert    用于指示该widget当前是否处于上电状态,invert则用于表明power字段是否需要逻辑反转。

active connected    分别表示该widget是否处于激活状态和连接状态,当和相邻的widget有连接关系时,connected位会被置1,否则置0。

new   我们定义好的widget(snd_soc_dapm_widget结构),在注册到声卡中时需要进行实例化,该字段用来表示该widget是否已经被实例化。

ext    表示该widget当前是否有外部连接,比如连接mic,耳机,喇叭等等。

force    该位被设置后,将会不管widget当前的状态,强制更新至新的电源状态。

ignore_suspend new_power power_checked    这些电源管理相关的字段。

subseq    该widget目前在上电或下电队列中的排序编号,为了防止在上下电的过程中出现pop-pop声,DAPM会给每个widget分配合理的上下电顺序。

*power_check    用于检查该widget是否应该上电或下电的回调函数指针。
event_flags    该字段是一个位或字段,每个位代表该widget会关注某个DAPM事件通知。只有被关注的通知事件会被发送到widget的事件处理回调函数中。
*event    DAPM事件处理回调函数指针。
num_kcontrols *kcontrol_news **kcontrols    这3个字段用来描述与该widget所包含的kcontrol控件,例如一个mixer控件或者是一个mux控件。

sources sinks    两个链表字段,两个widget如果有连接关系,会通过一个snd_soc_dapm_path结构进行连接,sources链表用于链接所有的输入path,sinks链表用于链接所有的输出path。

power_list    每次更新整个dapm的电源状态时,会根据一定的算法扫描所有的widget,然后把需要变更电源状态的widget利用该字段链接到一个上电或下电的链表中,扫描完毕后,dapm系统会遍历这两个链表执行相应的上电或下电操作。
dirty    链表字段,widget的状态变更后,dapm系统会利用该字段,把该widget加入到一个dirty链表中,稍后会对dirty链表进行扫描,以执行整个路径的更新。
inputs    该widget的所有有效路径中,连接到输入端的路径数量。
outputs    该widget的所有有效路径中,连接到输出端的路径数量。
*clk    对于snd_soc_dapm_clock_supply类型的widget,指向相关联的clk结构指针。

      以上我们对snd_soc_dapm_widget结构的各个字段所代表的意义一一做出了说明,这里只是让大家现有个概念,至于每个字段的详细作用,我们会在以后相关的章节中提及。

2. widget的种类

     在DAPM框架中,把各种不同的widget划分为不同的种类,snd_soc_dapm_widget结构中的id字段用来表示该widget的种类,可选的种类都定义在一个枚举中:

/* dapm widget types */
enum snd_soc_dapm_type {......}

snd_soc_dapm_input     该widget对应一个输入引脚。
snd_soc_dapm_output    该widget对应一个输出引脚。
snd_soc_dapm_mux    该widget对应一个mux控件。
snd_soc_dapm_virt_mux    该widget对应一个虚拟的mux控件。
snd_soc_dapm_value_mux    该widget对应一个value类型的mux控件。
snd_soc_dapm_mixer    该widget对应一个mixer控件。
snd_soc_dapm_mixer_named_ctl    该widget对应一个mixer控件,但是对应的kcontrol的名字不会加入widget的名字作为前缀。
snd_soc_dapm_pga    该widget对应一个pga控件(可编程增益控件)。
snd_soc_dapm_out_drv    该widget对应一个输出驱动控件
snd_soc_dapm_adc    该widget对应一个ADC 
snd_soc_dapm_dac    该widget对应一个DAC 
snd_soc_dapm_micbias    该widget对应一个麦克风偏置电压控件
snd_soc_dapm_mic    该widget对应一个麦克风。
snd_soc_dapm_hp    该widget对应一个耳机。
snd_soc_dapm_spk    该widget对应一个扬声器。
snd_soc_dapm_line     该widget对应一个线路输入。
snd_soc_dapm_switch       该widget对应一个模拟开关。
snd_soc_dapm_vmid      该widget对应一个codec的vmid偏置电压。
snd_soc_dapm_pre      machine级别的专用widget,会先于其它widget执行检查操作。
snd_soc_dapm_post    machine级别的专用widget,会后于其它widget执行检查操作。
snd_soc_dapm_supply           对应一个电源或是时钟源。
snd_soc_dapm_regulator_supply  对应一个外部regulator稳压器。
snd_soc_dapm_clock_supply      对应一个外部时钟源。
snd_soc_dapm_aif_in            对应一个数字音频输入接口,比如I2S接口的输入端。
snd_soc_dapm_aif_out          对应一个数字音频输出接口,比如I2S接口的输出端。
snd_soc_dapm_siggen            对应一个信号发生器。
snd_soc_dapm_dai_in           对应一个platform或codec域的输入DAI结构。
snd_soc_dapm_dai_out        对应一个platform或codec域的输出DAI结构。
snd_soc_dapm_dai_link         用于链接一对输入/输出DAI结构。

我们从es8316.c中挑选一个看一下:

static const struct snd_soc_dapm_widget es8316_dapm_widgets[] = {
	SND_SOC_DAPM_SUPPLY("Bias", ES8316_SYS_PDN, 3, 1, NULL, 0),
	SND_SOC_DAPM_SUPPLY("Analog power", ES8316_SYS_PDN, 4, 1, NULL, 0),
	SND_SOC_DAPM_SUPPLY("Mic Bias", ES8316_SYS_PDN, 5, 1, NULL, 0),
    .......
}

3. widget之间的连接器:path(struct snd_soc_dapm_path)

      之前已经提到,一个widget是有输入和输出的,而且widget之间是可以动态地进行连接的,那它们是用什么来连接两个widget的呢?DAPM为我们提出了path这一概念,path相当于电路中的一根跳线,它把一个widget的输出端和另一个widget的输入端连接在一起,path用snd_soc_dapm_path结构来描述:

/* dapm audio path between two widgets */
struct snd_soc_dapm_path {
	const char *name;

	/*
	 * source (input) and sink (output) widgets
	 * The union is for convience, since it is a lot nicer to type
	 * p->source, rather than p->node[SND_SOC_DAPM_DIR_IN]
	 */
	union {
		struct {
			struct snd_soc_dapm_widget *source;
			struct snd_soc_dapm_widget *sink;
		};
		struct snd_soc_dapm_widget *node[2];
	};

	/* status */
	u32 connect:1;	/* source and sink widgets are connected */
	u32 walking:1;  /* path is in the process of being walked */
	u32 weak:1;	/* path ignored for power management */
	u32 is_supply:1;	/* At least one of the connected widgets is a supply */

	int (*connected)(struct snd_soc_dapm_widget *source,
			 struct snd_soc_dapm_widget *sink);

	struct list_head list_node[2];
	struct list_head list_kcontrol;
	struct list_head list;
};

      当widget之间发生连接关系时,snd_soc_dapm_path作为连接者,它的source字段会指向该连接的起始端widget,而它的sink字段会指向该连接的到达端widget,还记得前面snd_soc_dapm_widget结构中的两个链表头字段:sources和sinks么?widget的输入端和输出端可能连接着多个path,所有输入端的snd_soc_dapm_path结构通过list_sink字段挂在widget的souces链表中,同样,所有输出端的snd_soc_dapm_path结构通过list_source字段挂在widget的sinks链表中。这里可能大家会被搞得晕呼呼的,一会source,一会sink,不要紧,只要记住,连接的路径是这样的:起始端widget的输出-->path的输入-->path的输出-->到达端widget输入。

图1    widget通过path进行连接

      另外,snd_soc_dapm_path结构的list字段用于把所有的path注册到声卡中,其实就是挂在snd_soc_card结构的paths链表头字段中。如果你要自己定义方法来检查path的当前连接状态,你可以提供自己的connected回调函数指针。

      connect,walked,walking,weak是几个辅助字段,用于帮助所有path的遍历。

4. widget的连接关系:route(struct snd_soc_dapm_route)

      通过上一节的内容,我们知道,一个路径的连接至少包含以下几个元素:起始端widget,跳线path,到达端widget,在DAPM中,用snd_soc_dapm_route结构来描述这样一个连接关系:

struct snd_soc_dapm_route {
        const char *sink;
        const char *control;
        const char *source;
        int (*connected)(struct snd_soc_dapm_widget *source,
                         struct snd_soc_dapm_widget *sink);
};

      sink指向到达端widget的名字字符串,source指向起始端widget的名字字符串,control指向负责控制该连接所对应的kcontrol名字字符串,connected回调则定义了上一节所提到的自定义连接检查回调函数。该结构的意义很明显就是:source通过一个kcontrol,和sink连接在一起,现在是否处于连接状态,请调用connected回调函数检查。
      这里直接使用名字字符串来描述连接关系,所有定义好的route,最后都要注册到dapm系统中,dapm会根据这些名字找出相应的widget,并动态地生成所需要的snd_soc_dapm_path结构,正确地处理各个链表和指针的关系,实现两个widget之间的连接,具体的连接代码分析,我们留到以后的章节中讨论。

static struct snd_soc_codec_driver soc_codec_dev_rt5651 = {
	.dapm_routes = rt5651_dapm_routes,
}
snd_soc_register_codec(&i2c->dev, &soc_codec_dev_rt5651,rt5651_dai, ARRAY_SIZE(rt5651_dai));
	/*machin之后最终导致该函数被调用*/
	static int snd_soc_instantiate_card(struct snd_soc_card *card)
		soc_probe_link_components(card, i, order);
			soc_probe_component(card, component);
				snd_soc_dapm_add_routes(dapm, component->dapm_routes,component->num_dapm_routes);
					snd_soc_dapm_add_route(dapm, route);	
						/*创建一个path*/
						snd_soc_dapm_add_path(dapm, wsource, wsink, route->control,route->connected);				

参考文章:08.音频系统:第003课_Linux音频驱动程序:第005节_DAPM_widget_route_path_江南才尽,年少无知!的博客-CSDN博客

  • 2
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
ALSA(Advanced Linux Sound Architecture)是Linux内核中的音频驱动框架,它提供了一套完整的音频处理流程,包括音频采集、音频处理和音频播放等功能。ALSA框架的设计目标是提供一个高效、灵活、可靠的音频处理框架,让开发人员能够方便地开发音频应用程序。 ALSA框架的核心包括以下几个组件: 1. 驱动程序:驱动程序是ALSA框架的核心组件,负责管理音频设备硬件,并提供音频数据输入输出的接口。ALSA驱动程序一般由硬件厂商或开源社区开发,可以通过内核模块的形式加载到Linux内核中。 2. 应用程序接口:ALSA框架提供了一套完整的应用程序接口,包括ALSA库和ALSA命令行工具。ALSA库提供了一组API,让开发人员能够方便地访问ALSA驱动程序提供的音频数据输入输出接口。ALSA命令行工具则提供了一组命令行工具,让用户能够方便地对音频设备进行配置和管理。 3. 中间件:ALSA框架还提供了一些中间件组件,如MIDI子系统、混音器子系统等,用于提供更高级的音频处理功能。 ALSA框架的音频处理流程如下: 1. 音频采集:当音频设备接收到音频信号时,ALSA驱动程序将音频信号采集到内存中,并通过DMA(直接内存访问)将音频数据写入音频缓冲区。 2. 音频处理:ALSA驱动程序将音频信号从音频缓冲区读取到内存中,然后对音频数据进行处理。音频处理包括音频格式转换、音频采样率转换、音频混音等处理。 3. 音频播放:ALSA驱动程序将处理后的音频数据从内存中读取到音频缓冲区,并通过DMA将音频数据传输到音频设备中进行播放。 总之,ALSA框架提供了一套完整的音频处理流程,让开发人员能够方便地开发音频应用程序,并提供了一组API和命令行工具,方便用户对音频设备进行配置和管理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值