Hello! Here is Kite's blog,
Welcome to communicate with me.
I have analyzed the problem of freezing in an article before: Android Audio Subsystem (6)------ Analysis of the problem of freezing sound
in camera Play 192KHz music scene.
Steps to reproduce:
1. Open QQ Music to play 192K music
2. Turn on the switch to allow other apps to play
3. Enter Netease Cloud Music to play 192K music
4. Turn on the switch to allow other apps to play
At this time, pay attention to listening to digital headphones, the probabilistic music will suddenly freeze!
Looking for a test to come to the log analysis, because it is not externally stuck, so there is no ivdump to read. After reading the dump audio file passed down from the service layer, no abnormalities are found, indicating that there is nothing wrong with the audio source. Continue to read the log , Caton time:
17:54:33.114822 1599 1599 D LongshotDump: takeScreenshot : PASS
It shows that the freeze time given by the tester occurred around 17:54:33 , so let’s get started!
After looking at the log, I found that:
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!!
It seems that an underrun has occurred, there is no data to mixer, so there is no data to play, and it freezes.
This is due to the fact that the upper layer did not transmit the data in time, so we have to analyze the trace again~
Open the perfetto tool website: https://ui.perfetto.dev/#!/viewer
Import the captured trace file, search for surfaceflinger, check the time point, and see the time point including 17:54:33 :
I found that the trace contains the abnormal occurrence point of the problem, so I feel relieved (trace sometimes may not be able to catch the problem occurrence point...)
Star nRdy, AudioOut, mix, write these threads respectively:
It is found that the AudioOut thread does have a large gap and has not been scheduled normally. This is the write thread of AudioOut in the framework service layer, indicating that the write thread of the upper layer has not been scheduled normally, resulting in no data written down in the upper layer, and there is no data processing in the mix. No data is written to the kernel, so it freezes.
After looking at the interval time, the freeze time is around 270ms:
So, why does this happen?
Look forward and compare the AudioOut situation during normal playback and abnormal situations:
it can be seen that normally AudioOut is being executed normally, and the running time is relatively long and regular, about 21ms Write once:
then Abnormal situation, that is, the situation of AudioOut when it is stuck:
It can be seen that there are many runnables. Compared with runnable, the execution time of running is very short. As we said in the previous article:
runnable thinks too much about whether the CPU is too busy and cannot Complete schedules in a timely manner .
So I wonder if the CPU load is too heavy at the moment, so I also checked the CPU loading situation synchronously, and found that in the picture above, CPU0~CPU4 are not running other things except QQ music, but CPU5 has been preempted by AudioIn ! CPU6 is running AudioOut, but at least it is not preempting all the time, and it is scheduling.
Let's enlarge the view and see the overall CPU loading situation:
one color represents a thread, and if a CPU is colorful, its scheduling is normal, but now it can be found that there is a large section of yellow, that is, AudioIn , CPU has been frequently preempted by AudioIn! ! !
This is rather strange, because the test scene is to play 192KHz music, and it is not recording...
Click on it and look, the thread number of this AudioIn is 9166. Then I checked:
AudioIn_46 9166 com.google.android.googlequicksearchbox
Outrageous, it turned out to be you again! ! ! Google Assistant!
I said why there is a recording. It turns out that Google Assistant is sneaking around in the background, but why does it seize the CPU so frequently?
The problem is that Google's APP is not very clear about its logic, and it can't be changed. Maybe it is caught in an infinite loop of some logic? ? ?
Checking the log in the HAL, I found some ReadThread timeouts. Is it related to this?
When I continued to study, I found that this problem did not reappear. . . . . .
I heard from colleagues that Google Assistant often interferes, but I can’t tell you what the specific situation is. Alas, if anyone knows about this situation, please leave a message to let us know.