Android底层音频声道耳机插头和开关壳体的发展

Android潜在的发展耳机插头连接到音频频道切换的例子

因为使用的是耳机 麦克分离式的耳机,所以要分别上报事件。在Android系统层耳机插孔的检測是基于/sys/class/switch/h2w/state的值来推断的(以4.4.4_r2为样例位于WiredAccessoryManager.java)。

仅仅要在内核中实现一个「或真或假」的基于switch类的h2w开关。Android系统就能够监听到插拔信息。

在播放音乐的时候插入耳机,使用tinymix(參考:Android音频底层调试-基于tinyalsa)命令能够查找到Playback Path的值从SPK变为HP_NO_MIC,就能够说明耳机插拔软件检測正常了。

# tinymix 

Mixer name: ‘RK_RK616_TINY‘

Number of controls: 7

ctl type num name                                     value

0 ENUM 1 Playback Path                            HP_NO_MIC

1 ENUM 1 Capture MIC Path                         MIC OFF

2 ENUM 1 Voice Call Path                          OFF

3 ENUM 1 Voip Path                                 OFF

4 INT 2 Speaker Playback Volume                  24 24

5 INT 2 Headphone Playback Volume                24 24

6 ENUM 1 Modem Input Enable                       ON

可是喇叭还在响,说明没有被关闭。查查原理图「功放上的控制脚」是在哪个GPIO上接着呢。

依据手冊得出仅仅要GPIO2_D7能够输出低电平就能实现喇叭的关闭,使用万用表測得在插入耳机后该管脚仍然为高电平。查看代码改动记录在上一个版本号同事是直接在rk_headset.c耳机插拔程序中改动将其拉低的,这样能够实现可是认为不妥。Android上层应该也是有音频通道切换的。依据上层来控制比較好。

这样插入耳机的时候也能够强制开启喇叭。把「使用哪个音频通信的决定权」交给给用户。

这个应该是在内核中实现的,由于Alsa已经正常切换了,就说明上层已经调用对应的接口了。从驱动中来分析。

设备资源:能够看到Speak和handphone的使能GPIO都给的是RK30_PIN2_PD7。

static struct rk616_platform_data rk616_pdata = {

.power_init = rk616_power_on_init,

.power_deinit = rk616_power_deinit,

.scl_rate   = RK616_SCL_RATE,

.lcd0_func = INPUT,             //port lcd0 as input

.lcd1_func = INPUT,             //port lcd1 as input

.lvds_ch_nr = 1,                //the number of used lvds channel

.hdmi_irq = RK30_PIN2_PD6,

.spk_ctl_gpio = RK30_PIN2_PD7,

.hp_ctl_gpio = RK30_PIN2_PD7,

};

设备驱动中控制音频输出通道的函数:

static int rk616_playback_path_put(struct snd_kcontrol *kcontrol,

struct snd_ctl_elem_value *ucontrol)

{

......

case HP_PATH:

case HP_NO_MIC:

case RING_HP:

case RING_HP_NO_MIC:

rk616_set_gpio(RK616_CODEC_SET_SPK, GPIO_LOW);

if (pre_path == OFF)

rk616_codec_power_up(RK616_CODEC_PLAYBACK);

snd_soc_update_bits(codec, RK616_SPKL_CTL,

RK616_VOL_MASK, HPOUT_VOLUME); //, volume (bit 0-4)

snd_soc_update_bits(codec, RK616_SPKR_CTL,

RK616_VOL_MASK, HPOUT_VOLUME);

rk616_set_gpio(RK616_CODEC_SET_HP, GPIO_HIGH);

break;

......

}

可见在输出到耳机通道时,禁用 SPEAKER和使能HP都是设置的GPIO_HIGH,最后RK30_PIN2_PD7仍然为高电平,没有禁用SPEAKER。原理图并没有单独的耳机的使能管脚。在资源中将hp_ctl_gpio设置为INVALID_GPIO。问题得以解决。

额外收获:原理耳机那里一直都是有音频输出的,不管插入不插入耳机;插入耳机时不过将SPEAKER禁止了。

误入的歧途:

1.误以为要去看Android上层代码在各种类中追寻了非常久。真是浪费时间,假设使用tinymix查看音频通道切换正常,说明内核以上的都没有问题了,出问题也是出在了内核以及硬件上。

总结:庞大的Android系统容不得你每一块都了解的非常仔细,可是假设会非常好的划分层次。问题就会非常好解决。记录的重点不在于详细的型号版本号等等比較虚拟方面,但是,在这样的问题善于分析的头脑面对。

版权声明:本文博客原创文章。博客,未经同意,不得转载。

时间: 2024-08-27 16:03:10

Android底层音频声道耳机插头和开关壳体的发展的相关文章

Android底层开发之耳机插拔与音频通道切换实例

Android底层开发之耳机插拔与音频通道切换实例 由于使用的是耳机 麦克分离式的耳机,所以要分别上报事件.在Android系统层耳机插孔的检测是基于/sys/class/switch/h2w/state的值来判断的(以4.4.4_r2为例子位于WiredAccessoryManager.java). 只要在内核中实现一个「或真或假」的基于switch类的h2w开关.Android系统就可以监听到插拔信息. 在播放音乐的时候插入耳机,使用tinymix(参考:Android音频底层调试-基于ti

Android底层开发之音频输入通道的软硬件分析

Android底层开发之音频输入通道的软硬件分析 我们都知道耳机Mic集成在一直的那种四段耳机Mic插头是Android设备上比较常用.但是也会有分开的情况,比较如果在普通的PC机中装Android系统,那么就是这种情况.所以就有必要对音频输入通道的软件硬件进行统一的分析一下,接下来分析一个实例. 该设备的硬件连接为:基于3157的模拟开关实现的 通道切换. 设备是完全靠硬件实现的,那么就没有软件的什么工作了.但是这并不是一个理想的实现方法,真下的实现方法应该是所有的Mic都是并行的,每个Mic

Android底层开发之Audio HAL

http://blog.csdn.net/kangear/article/details/44939429 Android底层开发之Audio HAL 在Android音频底层调试-基于tinyalsa中以「抛开Android的天生复杂,回归嵌入式Linux的本质」的方式介绍如何调试Linux内核中的音频驱动. 这里向上再伸展一下进入HAL层,看是如何将tinyalsa封装给Frameworks使用的. 基于4.2.2版本源码进行讨论.Android官方教程是Audio Implementing

Android底层开发之Linux输入子系统要不要推断系统休眠状态上报键值

Android底层开发之Linux输入子系统要不要推断系统休眠状态上报键值 题外话:一个问题研究到最后,那边记录文档的前半部分基本上都是没用的,甚至是错误的. 重点在最后,前边不过一些假想猜測. http://blog.csdn.net/kangear/article/details/40072707 在调试一下红外遥控器input驱动时,直接採用的是一个半成品的驱动在上边实现的自己的设备的匹配,但同一时候遇到了一些关于input输入子系统的疑惑. 按键一般有「按下和抬起」两个状态一般使用0和1

Android底层开发之Linux输入子系统要不要判断系统休眠状态上报键值

Android底层开发之Linux输入子系统要不要判断系统休眠状态上报键值 题外话:一个问题研究到最后,那边记录文档的前半部分基本上都是无用的,甚至是错误的.重点在最后,前边仅仅是一些假想推测. http://blog.csdn.net/kangear/article/details/40072707 在调试一下红外遥控器input驱动时,直接采用的是一个半成品的驱动在上边实现的自己的设备的匹配,但同时遇到了一些关于input输入子系统的疑惑. 按键一般有「按下和抬起」两个状态一般使用0和1来分

[android底层] hal硬件抽象层编写

两个与hal有关的结构体 hw_module_t ,hw_device_t 一.jni和hal之间的关系 Tip:几种app,jni,hal,framework之间的关系框架     这篇文章用的框架是第二种框架的编写,他们的关系如下: 可以看出jni主要通过pModule和pdevice来获取hal中的变量来操作hal层 二.jni操作hal 获取hal层:1.jni获取hal层的module和device对象 操作hal层:2.jni操作hal层 jni操作hal完整代码参考[android

【转】Android 底层开发的几点

我干了3年Android sdk开发,觉得到了瓶劲没法更进一步,于是花了一年多点时间,大概摸到点门径.根据前辈的经验,Android底层完全入门需要两年. 先说下我的入门过程:第零步,下载源码,我下的4.2的,框架层源码10G,内核2G多,ctags给框架层建的标签文件都有600M,当时让我有点震撼,用的vim+ctags+cscope来阅读,还算不错,架构挺清晰的. 第一步,我找到了一本好书<Android的设计与实现 第一卷>它讲了Android框架层的启动,初始化,服务框架初始化,Bin

Android底层驱动开发(一)

1   Android为什么要加入硬件抽象层HAL A    统一硬件调用接口,所以利用HAL屏蔽linux驱动的复杂不统一的接口 B   解决GPL版权问题,由于linux内核基于GPL协议,这个GPL协议需要开源,而Android遵守Apache License2.0协议,这个协议不要求开源,因此google玩了个穿越,将原本位于Linux驱动中的敏感代码(业务逻辑代码)向上移动了一层,这样这些敏感代码就拜托了GPL协议的束缚,那些不想开源的linux驱动作者不想开源现在就可以不用开源了.

如何穿越到android底层

对于android开发,实际上大部分工作都是在应用层,但为了体现"技术含量",以及"知其所以然",以便在遇到问题是不至于束手无策.因此有必要了解底层的工作机制. 由于android是开源的系统,因此学习其内部的工作机制是非常容易的,目前也有一些关于android源码分析的书籍. 我一直认为,应用层的开发和底层没什么太大的关系,不过有一次因为应用权限的问题,也算是对android framework层有一些了解了,借助一本源代码分析的书籍了解android的工作原理并