Hello! Here is Kite's blog,
Welcome to communicate with me.
In fact, we know that in mobile phones, in addition to the camera and overall performance, there is another most critical aspect for users: power consumption.
Power consumption has always been a concern of users. If users find that the power consumption is soaring when they use their mobile phones, it is estimated that people will be sprayed to death on the Internet.
So here, throwing bricks and starting jade, put a digital headset to play music and analyze the problem of high power consumption, for learning reference only.
background
[Preconditions] Airplane mode, default volume, manual off screen
[Operation steps]
1. Insert the digital headset into the mobile phone, turn off the sound effect, and adjust to the default media volume
2. Turn on the music player and add "Test Special Music.mp3" to the playlist
3. Click to play the song and turn off the screen manually within 2 seconds, and record the average current for 2 minutes after playing for 45 seconds. Sound effect
switch position: Settings - Sound and Vibration - Global sound effect (the name of the sound effect may be different for different mobile phones here)
[Actual Result] The test version S is 32.4mA larger than the R comparison version
[Expected result] The difference between the test version and the comparison version is within 3mA
Let me explain here, the same mobile phone, after upgrading from Android R to Android S, after the upgrade, the scene of digital earphone playing music on the S version is 32mA more than the original Android R.
Dismantling of power consumption
Because the same mobile phone is used, the hardware is the same configuration, and the power consumption can be ruled out to be caused by the hardware.
Use the power consumption board to disassemble the power consumption data:
I will code some irrelevant data to avoid trouble.
The picture above is a dismantling diagram of power consumption. On the left is the data of Android R, and on the right is the data of Android S. It can be clearly seen from the disassembled power consumption that the main difference in power consumption is on the BB, the large core (PROCB) is 20mA, The small core (PROCL) is 30mA, compared with the normal Android R version, the large core (PROCB) is 5mA, and the small core (PROCL) is 8mA.
Analyze systrace
Further capture the trace to analyze which thread on the CPU is causing the abnormal power consumption. The capture trace analysis is as follows:
It is found that there is a thread in the trace that runs for the longest time: mtk.mp3.decoder, which is suspected to be the decoder consumes power consumption.
Communicating with colleagues in charge of encoding and decoding, MTK did introduce the C2 decoding framework on Android S, but this decoder mainly runs on the small core, and the power consumption is disassembled. The power consumption difference of the large core is 15mA, and the power consumption of the small core is different. There is 22mA, theoretically an increase in C2 load would not introduce as much as 32mA.
In order to further test whether the power consumption is caused by the C2 codec, an experiment was done to convert the MP3 file to WAV format for playback, which can avoid decoding the music file.
In the comparison test, the difference in power consumption between playing WAV and MP3 is about 20mA , and no significant decrease in power consumption has been found. It can be determined that the extra power consumption should not be caused by the decoder (for hard decoding loads to increase power consumption gain, MTK has done 1080P30fps video Play, the C2 architecture is up to 5ma larger than the OMX).
But at least it can be concluded that playing MP3 music will consume about 10mA more power than playing WAV format music, but it is not the main cause of this question.
After communicating with the tester again, it was found that in the same scenario, the analog headset has no power consumption problem, and only the digital headset has problems.
This is more interesting, because in the framework code of the audio service layer, there is no distinction between analog headphones and digital headphones, and the playback process of the two is the same!
Grab the systrace comparison results of Android S and Android R again in the digital headset scenario (S on the left and R on the right):
Mix thread digital headset S is more expensive than R:
extractor thread digital headset S is more expensive than R:
music player APP digital headset The overhead S is larger than R, and there are also more threads:
Music is playing in the background with the screen off, and the systemUI on the digital headset S is still eating up performance.
system server Digital headset S has 11 more threads than R.
Surfaceflinger overhead digital headset S is greater than R.
From the perspective of systrace, there is no new load on Audioserver, which is the same as I thought before, and the load on AudioserverS is still lower than R.
Currently two systraces can be confirmed:
- Added payload to c2 decoder.
- The music app adds load.
- Surfaceflinger adds load.
- The hal layer mix thread adds new load.
When the problem comes to this point, I find it rather strange, because both Android S and Android R are tested with the same music app, and this part should not cause an increase in load.
The final confirmation results are as follows:
- c2 will not increase more than 5mA at most, not a major power consumption difference.
- Both S and R use the same version of the music app, which can be excluded.
- Off-screen playback has nothing to do with display, it should be introduced by logkit for bright-screen operation.
- Replace the mix thread code in hal on R to S, and there is no significant drop in power consumption.
I wondered if there was something wrong with the previous systrace, so I grabbed the S and R systrace again for comparison:
it can be seen that the overhead of the Mix thread S is similar to that of R, and generally speaking, the overhead of S in hal is higher than that of R. Low, theoretically the power consumption will not become higher, but lower.
At this point, I feel strange again here. The dismantling of power consumption shows that the difference in power consumption is mainly caused by the CPU, mainly in the upper layer (the bottom code generally only does HW enable, which is hardware power consumption, not CPU power consumption), and the two The systrace of the second capture is very different, very unstable, and the performance of cpu loading is completely different. But the total load shows that the load of S is lower than that of R, so the difference in power consumption should not be on the CPU, which is contradictory to the conclusions obtained from dismantling the power consumption.
Low-level investigation
However, the problem needs to be further analyzed. At present, the upper layer is basically checked, and the bottom layer is started to be checked, and tinyplay is used to play music tests, which can shield the upper layer differences. Tinyplay playback only involves the bottom layer audio driver, and the result...
It is found that the power consumption of digital earphones on Android S and Android R is not much different in the scene of tinyplay playing music, which is about 2-3mA, and the underlying driver and hardware reasons are basically ruled out.
At this time, both the upper and lower layers have been checked, and the problem is still not found...
CPU differences
Based on the dismantling of power consumption provided by the hardware, the difference in power consumption is mainly in the CPU. Combining with what I said before, I feel that there is a problem with systrace capture, so I decided to continue to capture systrace analysis.
This time, use scripts and adb commands to grab systrace and put it in chrome://tracing/ for analysis!
After many experiments and grabbing systrace, it was found that the consumption difference between the comparison threads was not big, and no thread was found to have a relatively large overhead.
However, it can be seen from systrace that
the thread consumption on Android R is relatively evenly distributed on CPU0~CPU7.
Android S threads are mainly distributed on CPU0 ~ CPU4, and CPU5 ~ CPU7 are basically not running anything.
This is more intriguing.
Further experiments found that on Android S, after each flashing is completed, as long as the power consumption test is performed as soon as possible, the power consumption is normal, and the power consumption is the same as that of Android R. , as long as the phone changes from off screen to bright screen and unlocked, the power consumption becomes abnormal when the test is performed again, that is, the power consumption will be 32mA more than that of Android R: the key data will be coded to avoid trouble
. It can be seen that the test after turning off the screen and turning on the screen is indeed a bit higher than the previously measured power consumption.
Does it have anything to do with turning on and off the screen? ? ? But then again, why don't analog headphones have this problem?
Put two more current diagrams:
the above picture is the current diagram of the digital headset playing music on Android S before the screen is turned on and off, and the power consumption is normal at this time.
The picture above is the current diagram of digital headphones playing music after the screen is turned on and off on Android S. At this time, the power consumption is abnormal.
In order to avoid trouble, the data has been coded. You can compare the two pictures and find that when it is normal, the bottom current of power consumption is at the position of scale 6. When it is abnormal, the bottom current of power consumption soars to the position of fast scale 7.
It means that it may not be because a certain thread in the digital headset playback process causes abnormal power consumption, but the system power consumption is abnormal, resulting in an increase in the bottom current . No wonder I have checked systrace many times and found no clues.
Combined with the previous systrace, it was found that the CPU loading status was abnormal, and MTK gave instructions to check the CPU frequency:
cat /proc/cpufreq/MT_CPU_DVFS_CCI/cpufreq_freq
It was found that the CPU frequency is about 800M when the power consumption is normal, and the CPU frequency directly soars to 1.6G when the power consumption is abnormal. And it never came down...
At this point in the analysis of the problem, it is slowly getting out of the scope of audio. It is no longer something that a small audio engineer like me can cover. It needs colleagues who are responsible for the kernel to intervene.
I talked about this with the old kernel buddies, and they both told me that there is a patch!
It turned out that they fixed a problem the day before yesterday, the problem that the super-large core was not released. After I applied this patch, the power consumption was normal...
Good guy, I just put it here and analyzed it for several weeks, but it turned out that it wasn't the audio's fault, and I wiped my ass again, and I can't sleep anymore! ! !