又是一个数字耳机的坑，又被我遇到了，唉。。。

测试反馈：客观测试，数字耳机通话上行响度不达标（非必现，极大概率）。

因为我是做手机的嘛，手机场景这么多，直接面向用户的，所以测试非常多，也考虑用户感受，不然如果手机不好用估计要被用户喷死。。。。。

这里就分为主观测试和客观测试：
主观测试：音频测评工程师就带上数字耳机通话，肉身感受通话音频效果质量。
客观测试：把手机放在音频实验室（有一个人头模型），给人工耳挂上耳机，人工嘴挂上耳机mic，用机器来测试。

然后实验室里面还有一个伪基站，手机用白卡来打电话，通话的各项数据会被伪基站捕捉，然后可以直观的看到。

测试就和我反馈，上行响度不达标。但是主观测试没有这个问题。

同样是打电话测试，主观测试不复现，客观测试就复现？？？这是在开玩笑吗

行，响度不达标应该是哪里增益没设对，或者音量曲线没调好，那给我抓一份log我瞅瞅吧。

结果测试和我说了第二句话：没有log，因为一开MTKlog工具（DebugLogger）去抓log，问题就不复现了

这没有log我分析个啥？？？

然后又和其他测试聊到，问题应该是通话无声，或者增益太小导致的听不见的无声？
这又给我真懵逼了，这是几个问题啊，没办法，没有log无法分析啊，只能和测试一顿py，接着尝试抓log，请加大力度！！！

因为MTKlog抓的东西比较多，所以尝试只抓部分log。只抓mobile log，只抓modem log，只抓VM log，只抓mobile log + VM log，只抓…

因为通话算法用的三方算法，所以也找了三方的人来一起看这个问题。

好不容易抓到一次log，发现ADSP里面bypass了aurisys，也就是ADSP里面没有跑三方的通话算法，可能是这里导致ul gain设置有问题。

MTK认为需要一份开机log才能知道为什么ADSP会走bypass，我天，抓log都够难的了，咋还能给你抓开机log啊。
继续抓，又抓到一份log，这份log里面ADSP没报错，但是没有抓到通话算法的dump，所以也没法证明是不是算法出了问题，至少这份log里面ADSP没有问题。

没办法，只能从通话算法这边想办法，尝试算法使用bypass参数，依旧不能解决这个问题，所以算法那边认为这题和通话算法无关。

因为开log就会导致问题不复现，所以猜测问题原因然后一遍修改一遍测试，看能否解决掉这个问题，然后也尽力去抓复现的log。结果占用测试人力过多，测试也恼了。。。。。。

唉，手机厂就这个毛病，节奏快，这才几天，就一直催解决，天天被催，测试也恼，没有人力了，要我研发自己去实验室测。。。。

因为没有有效log，分析进度实在不行啊，音频实验室在外地，只能我亲自出马了！！我一个研发居然也要我出差了，泪目。。。

出差去到实验室之后，我亲自试了下，确实很神奇！！不开log就能复现异常，开了log之后就死活不复现了。

一开始我以为是性能问题导致的，手机开启高性能模式之后也不起作用。

那我只能用出终极办法了，高端的调试方法往往就是一个朴素的命令：
adb shell logcat > D:\log.txt

结果，不是吧，啊sir，我就仅仅是logcat抓log，就又不复现了。。。这真是我碰到的最玄学的问题了。

然后我去仪器那里看了下，伪基站捕捉到的上行通话数据就是一条直线，看起来确实像是无声问题，我猜测应该和响度没啥关系，应该就是无声了。

然后我就蹲在实验室里面吭哧吭哧的抓log，终于发现了必现路径：

• 1.adb shell logcat > D:\log_first 开始抓取
• 2.通话（此时通话正常）
• 3.Ctrl-c取消logcat抓取（通话不挂断）
• 4.等待几秒
• 5.继续adb shell logcat > D:\log_second抓取log
• 6.此时通话异常就复现问题了
  而且我发现亮屏时问题就不复现，只有息屏时问题才复现（ 天知道，就这一句话，花费了我多少心力 ）

这题和亮灭屏有什么关系呢？

查看log_second这份log发现：

AudioUSBPhoneCallController: speechULThread(), proxy_read failed, ret -1, fail due to cannot read stream data: Streams pipe error, writeTimes 1249, fill mute data
AudioUSBPhoneCallController: speechULThread(), proxy_read failed, ret -1, fail due to cannot read stream data: Streams pipe error, writeTimes 1250, fill mute data
AudioUSBPhoneCallController: speechULThread(), proxy_read failed, ret -1, fail due to cannot read stream data: Streams pipe error, writeTimes 1251, fill mute data
看来确实是通话无声，和增益啥的响度没关系，是通话UL没有从数字耳机拿到数据，所以上行通话无声了。
 
进一步查看kernel log：
 
[ 2915.631642]  (1)[18169:usb_call_ul]usb 1-1: start in data endpoint #81
[ 2916.152638]  (2)[18169:usb_call_ul]usb 1-1: stop in data endpoint #81
[ 2916.162986] -(2)[18169:usb_call_ul]usb 1-1: start in data endpoint #81
[ 2916.644130]  (4)[18169:usb_call_ul]usb 1-1: stop in data endpoint #81
[ 2916.654690] -(4)[18169:usb_call_ul]usb 1-1: start in data endpoint #81
[ 2917.168865]  (4)[18169:usb_call_ul]usb 1-1: stop in data endpoint #81
发现数字耳机，USB一直在频繁连接和断开！！！
 
看起来是和USB有很大关系，然后我把问题进展同步给USB的同事之后，天杀的！他居然知道这个问题！！！
 USB那边表示：手机端作为host，插入otg后，息屏之后，系统会持有wake_lock导致系统不进休眠，所以为了降低系统功耗，改成了息屏之后，系统不再持有wake_lock锁，系统会进入休眠。
 
所以我说怎么log里面一直频繁断开USB！！！
 
之后尝试把USB补丁回退或者使用
 
echo test > /sys/power/wake_lock
做持锁试验，问题不在复现，得到解决。
 
唉，又给人背锅了，太惨了，最后解决方案是在通话时在Audio HAL里加锁，保证系统不会休眠，补丁验证通过，这个问题终于告一段落了。
                    你好！这里是风筝的博客，欢迎和我一起交流。又是一个数字耳机的坑，又被我遇到了，唉。。。测试原话反馈：客观测试，数字耳机通话上行响度不达标。因为我是做手机的嘛，手机场景这么多，直接面向用户的，所以测试非常多，也考虑用户感受，不然如果手机不好用估计要被用户喷死。。。。。这里就分为主观测试和客观测试：主观测试：音频测评工程师就带上数字耳机通话，肉身感受通话音频效果质量。客观测试：把手机放在音频实验室（有一个人头模型），给人工耳挂上耳机，人工嘴挂上耳机mic，用机器来测试。然后实验室里面还有一个伪
AudioManager：音频管理器
static getInstance()：获取AudioManager对象
getCurrentAudio()：获取当前加载的音频对象
getAudioName()：获取当前加载音频的名称（未保存的录音则表示为"录音"，其他情况则为文件名）
startRecord()：打开一个线程录音
finishRecord()：结束录音，将会替换当前加载的音频对象
save(String)：保存当前音频到指定文件
openNewAudioFile(String path)：打开音频文件
playAudio()：播放当前加载的音频
pauseAudio()：暂停当前的音频
setNowTime()：设置当前播放的时间
addPlayingListener()：添加音频播放监听器
private void openSco(){
    if (!audioManager.isBluetoothScoAvailableOffCall()) {
        Log.d(TAG, "系统不支持蓝牙录音");
        return;
欢迎和我一起交流。
Android framework中的代码每个平台基本都是大同小异，只有Hal上代码才是厂商特制，每个平台都不相同，这里以MTK平台为例，记录下MTK平台Hal audio音频录音代码流程。
调用大致流程如下
AudioALSAHardwa: openInputStream()
	AudioALSAStreamManager: openInputStream()
		AudioALSAStreamIn: AudioALSAStreamIn //new Audi
				
最近遇到一个关于modem crash的问题，机器modem发生错误之后，不仅重启自己，还把整个系统给重启了。这个对于客户来说，这是不允许的。所以，折中的方案是，在modem发生错误的时候，重启modem自身。
 使用ADB打开android shell环境，有这么一个文件夹：sys/bus/msm_subsys/devices，里面分别有三个文件夹：subsys0、subsys1、subs...
				
[DESCRIPTION]
对于MT6589、MT6572、MT6582的Speaker的客制化需求部分的一些整理。
一些可能的配置请参考下面的表格，Solution请根据序号参考对应的Solution.
外置PA的驱动，请参考如下方式完成：也可参考 [FAQ05881] [Audio Driver] 6589、6572、6582喇叭无声，软件上应该如何配置
把CUSTOM_KERNEL_
				
《android telephony原理解析与开发指南》是杨青平编写的一本关于Android手机通讯系统的原理和开发指南的书籍。本书主要介绍了Android手机通讯系统的工作原理、架构和相关开发技术。
首先，本书对Android手机通讯系统的工作原理进行了深入解析。Android手机通讯系统是由Android操作系统及其上层应用程序组成的，通过多个模块协同工作实现电话通信功能。本书从系统启动过程、应用层协议、信令流程等方面详细介绍了Android手机通讯系统的运行原理。
其次，本书介绍了Android手机通讯系统的架构。Android手机通讯系统的架构主要包括RIL、Telephony Service和Phone App等重要组件。作者详细解释了各个组件的功能和相互之间的关系，帮助读者理解Android手机通讯系统的整体架构。
同时，本书还提供了Android手机通讯系统开发的指南。作者从配置环境、开发工具和开发步骤等方面详细介绍了Android手机通讯系统的开发过程。读者可以学习到如何使用Android SDK进行开发，如何编写Telephony Service和Phone App等应用程序。
《android telephony原理解析与开发指南》是一本系统而实用的Android手机通讯系统开发指南。通过阅读本书，读者可以全面了解Android手机通讯系统的原理和架构，掌握Android手机通讯系统开发的技巧和方法。作为一名Android开发者，这本书将成为您在Android手机通讯系统开发中的实用指南。