Android如何找到正确的ALSA底层kcontrol接口?

昨天分析了一把snd_kcontrol，可以认为上层应用的确是通过名称标识name来遍历底层的snd_kcontrol链表，从而找到相匹配的kcontrol。见snd_ctl_find_id函数

[cpp] view plaincopy

1. /** 
2.  * snd_ctl_find_id - find the control instance with the given id 
3.  * @card: the card instance 
4.  * @id: the id to search 
5.  * 
6.  * Finds the control instance with the given id from the card. 
7.  * 
8.  * Returns the pointer of the instance if found, or NULL if not. 
9.  * 
10.  * The caller must down card->controls_rwsem before calling this function 
11.  * (if the race condition can happen). 
12.  */  
13. struct snd_kcontrol *snd_ctl_find_id(struct snd_card *card,  
14.                      struct snd_ctl_elem_id *id)  
15. {  
16.     struct snd_kcontrol *kctl;  
17.   
18.     if (snd_BUG_ON(!card || !id))  
19.         return NULL;  
20.     if (id->numid != 0)  
21.         return snd_ctl_find_numid(card, id->numid);  
22.     list_for_each_entry(kctl, &card->controls, list) {  
23.         if (kctl->id.iface != id->iface)  
24.             continue;  
25.         if (kctl->id.device != id->device)  
26.             continue;  
27.         if (kctl->id.subdevice != id->subdevice)  
28.             continue;  
29.         if (strncmp(kctl->id.name, id->name, sizeof(kctl->id.name)))  
30.             continue;  
31.         if (kctl->id.index > id->index)  
32.             continue;  
33.         if (kctl->id.index + kctl->count <= id->index)  
34.             continue;  
35.         return kctl;  
36.     }  
37.     return NULL;  
38. }  

今天继续跟踪Android音频系统时，发现无论如何都找不到Android与snd_kcontrol的联结点，无论是name还是numid（alsa_amixer controls打印出来的那个numid，即是内核层snd_kcontrol链表元素的numid）都找不到相关关键字。但是它确实可以进行调节音量等控制。后来我修改内核的Codec驱动，将音量控制的kcontrol.name换成其他字符串，重新编译，Android还是可以进行音量控制。

看起来有点像是通过numid来控制的，《Android音频HAL移植》一文有提到：“设备的切换就需要和驱动联调。例如，目前earpiece的id为10，那么就可以通过ALSA的amixer设置earpiece的开和关，以及大小。而id的值就需要做驱动的同事提供。”但是还不能就此肯定。目前也没有找到保存这些值的脚本文件。

继续以上问题，我在调节音量时，打印Codec寄存器的值，发现volume寄存器的值根本不会发生变化，但是音量确确实实是变化的。那时就在怀疑我们Android的音量调节不是通过硬件来实现的，而是有自身的sw mixer机制。晚上和Vic一起吃饭时，聊起这个，肯定了我的猜测。

[cpp] view plaincopy

1. status_t AudioFlinger::setMasterVolume(float value)  
2. {  
3.     // check calling permissions  
4.     if (!settingsAllowed()) {  
5.         return PERMISSION_DENIED;  
6.     }  
7.   
8.     // when hw supports master volume, don't scale in sw mixer  
9.     AutoMutex lock(mHardwareLock);  
10.     mHardwareStatus = AUDIO_HW_SET_MASTER_VOLUME;  
11.     if (mAudioHardware->setMasterVolume(value) == NO_ERROR) {  
12.         value = 1.0f;  
13.     }  
14.     mHardwareStatus = AUDIO_HW_IDLE;  
15.   
16.     mMasterVolume = value;  
17.     for (uint32_t i = 0; i < mPlaybackThreads.size(); i++)  
18.        mPlaybackThreads.valueAt(i)->setMasterVolume(value);  
19.   
20.     return NO_ERROR;  
21. }  

应该是Android允许开发者在HAL层实现hw mixer，当AudioFlinger探测到存在hw mixer时，则调用mAudioHardware->setMasterVolume()对volume寄存器进行设置，也不会对volume值进行scale。至于sw mixer如何使用scale值的，我没有深入探究。

以后实现hw mixer看看（反正到时也要实现EQ）效果，现在这个音量设置不是线性的，用硬件控制应该更好一点。

PS：标题就不用管它了，默认下Android根本不去找底层的kcontrol接口，而是使用自身的sw mixer。

分享到：

上一篇：snd_kcontrol探究

下一篇：shellcode之一：栈溢出

查看评论

8楼 doom661512011-06-25 00:17发表[回复]

好的，我都看看，你对dapm 和 snd_contorl 的分析对我帮助很大。
我这段时间在搞alsa这个东西。打算把它吃透，并整理出笔记。

7楼 sepnic2011-06-24 20:37发表[回复]

还有http://blog.csdn.net/sepnic/archive/2011/01/18/6150723.aspx。

6楼 sepnic2011-06-24 20:37发表[回复]

这篇文章是调android音量写的，后来发现android是软件调节的。关于硬件mixer方面的：http://blog.csdn.net/sepnic/archive/2011/04/20/6334922.aspx。请看看还有什么地方遗漏的或错误的

5楼 doom661512011-06-24 18:49发表[回复]

驱动初始化的时候做的：
int snd_ctl_add(struct snd_card *card, struct snd_kcontrol *kcontrol)
{
....
kcontrol-&gt;id.numid = card-&gt;last_numid + 1;
.....
}

4楼 doom661512011-06-24 18:43发表[回复]

“而id的值就需要做驱动的同事提供“
我理解是：numid是runtime的时候动态分配的。

3楼 doom661512011-06-24 18:42发表[回复]

“而id的值就需要做驱动的同事提供”
我理解是：numid是在runtime的时候动态分配的。
alsa确实是把简单问题复杂化，我还是喜欢oss的简单。

Re: sepnic2011-06-24 20:31发表[回复]

回复 doom66151：numid不是动态分配的，原则是按照kcontrols的注册顺序来分配的。就是说，你驱动不变的话，numid也不会动态改变，不过我不知道alsa-lib是否可以有接口来配置numid？

2楼 doom661512011-06-24 18:39发表[回复]

我理解的是：
input/output路径也是根据我们提供的两个数组 snd_soc_dapm_widget和snd_soc_dapm_route动态匹配好。alsa_lib里面的接口根据snd_soc_dapm_type来处理input/output切换这样的事件。

Re: sepnic2011-06-24 20:29发表[回复]

回复 doom66151：是的。这个我在另外一篇：http://blog.csdn.net/sepnic/archive/2011/04/20/6334922.aspx 有比较详细的分析。

1楼 doom661512011-06-24 18:39发表[回复]

“上层应用的确是通过名称标识name来遍历底层的snd_kcontrol链表”
上层又是如何知道驱动注册的controls的名字呢？

Re: sepnic2011-06-24 20:28发表[回复]

回复 doom66151：多谢兄弟的支持。上层可以用alsa_amixer controls这个命令来显示所有的controls名字。