Android音频子系统(七)------数字耳机播192KHz音乐卡顿问题解析

你好!这里是风筝的博客,

欢迎和我一起交流。


之前有分析过一篇卡顿的问题:Android音频子系统(六)------拍照音卡顿问题解析
这里再放一篇音频卡顿分析吧,区别于之前,这次是数字耳机播放192KHz音乐场景。

复现步骤:
1.打开QQ音乐播放192K音乐
2.打开允许其他应用播放开关
3.进入网易云音乐播放192K音乐
4.打开允许其他应用播放开关

此时注意听数字耳机,概率性的音乐会突然卡顿一下!

找测试要来了log分析,因为不是外放卡顿,所以就没有ivdump可以看了,看了下服务层传下的dump音频 文件,没发现异常,说明音源没啥问题,继续看了下log,卡顿时间:

17:54:33.114822  1599  1599 D LongshotDump: takeScreenshot : PASS

说明测试小哥给出的卡顿时间发生在17:54:33左右,好嘞,开搞!

log大概看了下,发现:

17:54:32.233839   877  1526 W audio_sw_mixer: T_HIFI=>T_PRIMARY underflow!!
17:54:32.233863   877  1526 W audio_sw_mixer: sw_mixer_wait_to_mix(), MIXER_PLAYBACK  , target T_PRIMARY    wait 7333 us timeout, path exit 0 start 1 ready 0 direct 0
17:54:32.233880   877  1526 W audio_sw_mixer: sw_mixer_do_mix(), MIXER_PLAYBACK  , path T_HIFI=>T_PRIMARY   , data 0 not enough
17:54:32.233888   877  1526 W audio_sw_mixer: sw_mixer_do_mix(), MIXER_PLAYBACK  , target T_PRIMARY   , no any ready path to mix!!

看起来是发生underrun了,没有数据可以mixer,所以没有数据可播,就卡顿了。
这属于上层没有及时传数据下来啊,又得抓trace分析了~

打开perfetto工具网站:https://ui.perfetto.dev/#!/viewer
导入抓到的trace文件,搜索surfaceflinger ,查看时间点,看到包含17:54:33这个时间点:
surfaceflinger

发现trace是有包含问题异常发生点的,那我就安心了(trace有时不一定能抓到问题发生点…)

分别星标nRdy、AudioOut、mix、write这几个线程:
write

发现AudioOut线程确实有一大段空白,没有被正常调度,这是framework服务层AudioOut的write线程,说明上层write线程没有被正常调度,导致上层没有数据写下来,mix就没数据处理了,HAL里就没数据write到kernel了,所以也就卡顿了。

看了下间隔时间,卡顿时间在270ms左右:
time
那么,为啥会导致这种情况呢?

往前看下对比看下正常播放时和异常情况卡顿时的AudioOut情况:
normal
可以看出,正常是AudioOut有在正常被执行,running运行时间比较长,也很规律,大概在21ms左右write一次:
21write
那么异常情况,也就是卡顿时的AudioOut情况呢:
error
可以看出,他的runnable非常多,对比runnable,runing执行的时间非常短,上篇文章我们就说过:
runnable过多考虑是否cpu过忙,无法及时完成调度

所以考虑是不是此刻CPU负载过重了,所以同步也看了CPU的loading情况,发现上面这张图,此刻CPU0~CPU4是除了QQ音乐,没有跑有其他东西,但是CPU5一直被AudioIn抢占着!CPU6跑的是AudioOut,但是起码没有一直抢占,有在调度。

我们把视图拉大,看下CPU整体loading情况:
load
一种颜色代表一个线程,某个CPU上五颜六色就说么它的调度还算正常,但是现在这个可以发现出现了大段的黄色,也就是AudioIn,CPU一直在被AudioIn频繁的抢占着!!!

这就比较奇怪了,因为测试场景是播放192KHz音乐,没有在录音才对…
9166
点开看了下,这个AudioIn的线程号是9166.然后我查了下:

AudioIn_46 9166 com.google.android.googlequicksearchbox 

离谱,原来又是你!!!Google助手!

我说怎么有个录音,原来是Google助手在后台鬼鬼祟祟作妖,但是它为什么会那么频繁的抢占住CPU呢?

问题是Google的APP也不太清楚它的逻辑是怎样的,改不了啊,可能是陷入了部分逻辑的死循环???

查看HAL里log倒是发现有些ReadThread的timeout情况,难道和这个有关?

正当我继续深究的时候,居然发现,这个问题不复现了。。。。。。
tuxue
听同事说Google助手经常会有干扰,但是具体是个什么情况,又说不清,唉,有大佬有知道这个情况的还望留言告知

猜你喜欢

转载自blog.csdn.net/Guet_Kite/article/details/123527476
今日推荐