Android音频子系统（八）------数字耳机通话无声问题解析

你好！这里是风筝的博客，

欢迎和我一起交流。

---

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

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

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

这里就分为主观测试和客观测试：
主观测试：音频测评工程师就带上数字耳机通话，肉身感受通话音频效果质量。
客观测试：把手机放在音频实验室（有一个人头模型），给人工耳挂上耳机，人工嘴挂上耳机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里加锁，保证系统不会休眠，补丁验证通过，这个问题终于告一段落了。