Hello! Here is Kite's blog,
Welcome to communicate with me.
Since I came to the mobile phone factory to move bricks last year, it has been a long time since I updated it. I am too busy. . . . . .
Now because of the epidemic, I am working from home. I took the time to sort out some audio problems I encountered recently for your reference.
The test reported a problem of sound freezing when taking pictures:
[Prerequisites] [Prerequistes] Dark environment
[Operation steps] [Operation steps] Click to take pictures in night scene mode
[Actual results] [Actual results] Sound freezing when taking pictures
emmm, the lagging problem is a commonplace in the audio, after getting the log, open the audio dump file and read it, mainly to check the ivdump signal.
ivdump is the feedback signal of the power amplifier, which feeds back the output signal of the power amplifier.
Open the ivdump of the normal camera sound:
It can be seen that the spectrum signal is relatively coherent and there is no stuttering.
Open abnormal camera sound ivdump:
It can be seen that there is an abnormality in the spectrum, the data is disconnected, and there is a vacancy of about 26ms, that is, there is a freeze.
It shows that the PA playback does appear to be stuck.
But further check the dump of the data to be written by the service layer in the framework to the HAL, that is, StreamOut.wav, no abnormality is found, indicating that the audio source data transmitted by the upper layer service is normal.
Check the dump of the data written by HAL to the kernel again, that is, TaskPlayback_dataout.pcm, which is also normal, which is quite strange.
As mentioned in the previous article, if there is no problem with the audio source, there are always two situations for the freeze problem:
1. Overrun: Writing data is fast, but playing data is slow, resulting in the buffer being full and causing freeze.
2. underrun: Writing data is slow and playing data is fast, resulting in empty buffer, no data to play, and freezes.
Open the kernel log and read:
- -(0)[13588:writer]snd_audio_dsp snd_audio_dsp: mtk_dsp_start() task id:10 adsp xrun
I searched in the simple log, and there is indeed xrun, but it is not marked whether it is overrun or underrun, and it is not as simple as the chip path I have been in contact with before. Nowadays, high-end chips are all equipped with ADSP, and it is really not easy to deal with DSP.
Moreover, there are many and complicated mobile phone scenes, so it is not good for me to change the buffer size at will, because it will increase the playback delay.
Now generally the Kernel and ADSP codes are maintained by the original chip factory, and the audio of our manufacturer is generally not very good-looking, so I usually start the analysis from the upper layer.
Caton problems are generally caused by performance reasons, and the systrace analysis was re-captured.
Check the log:
06:07:21.408285 19316 10173 D AudioTrack: start(45): prior state:STATE_STOPPED output 29 stream 1 session 225
06:07:21.408662 935 1227 D APM_AudioPolicyManager: startOutput() output +++ 29, stream 1, session 225
06:07:21 Time Track starts broadcasting, remember this time point.
Open the perfetto tool website: https://ui.perfetto.dev/#!/viewer
Import the captured trace files. There are many articles on the Internet that teach how to capture traces, so I won’t go into details here.
Search for surfaceflinger, check the time point, and see the time point including 06:07:21:
It means that this trace has a time when the abnormality is caught normally. The above nRdy is the played data, which means that this point is playing the camera sound, OK, and the log is right.
Afterwards, star nRdy, AudioOut, and write threads respectively:
nRdy is the data to be played transmitted by the service layer. You can see that the write thread of the HAL layer has an orange indication, which is as long as 27ms, and the article At the beginning, the interval between the camera sound stuttering is almost the same, and this is where something went wrong.
There are generally four states in systrace:
- running (running is too long to consider whether the thread is doing too much
- runnable (runnable considers too much whether the cpu is too busy to complete the scheduling in time
- Sleeping (sleeping is too much considered whether it is blocked by other threads
- uninterruptible sleep (too much uninterruptible sleep may cause IO to be too heavy
This orange is the Uninterruptible Sleep state, it seems to be the card IO, from perfetto, there is no non-IO or IO, and I am not sure what caused it. If you look at the wake-up relationship, look for the running state later, and find it is being blocked. who woke up:
It is found that com.oplus.camera wakes up the write thread in HAL, so it may have a relatively large relationship with the camera.
Continue to look at several other Uninterruptible Sleep states, check his running, it is kworker24035 wake up:
Looking at kworker24035, Uninterruptible Sleep did appear for a long time:
It seems that it is indeed caused by the thread number 24035!
Check the ps file to find out which thread 24035 is:
root 24035 24035 2 0 0 cmdq_pkt_wait_complete 0 D kworker/u16:3
It seems to be the cmdq_pkt_wait_complete function, but after looking at it, I don’t know who is calling this API. It seems to be public, embarrassing. . .
However, according to the previous analysis, the suspicion of the camera is relatively large. After communicating with the colleagues of the camera, they really gave a plan:
1. In the music playback scene, cancel the camera scheduling compensation, and resume the camera scheduling compensation when the playback stops.
2. Improve the small thread scheduling priority of the foreground playing app
3. Camera optimizes the load overhead
The camera colleague took these three axes down, and the problem really did not reappear.
To sum up, although the problem is not caused by the audio side, it is really tiring to analyze who caused the problem.
Postscript:
The perfetto tool that comes with Android can also capture traces:
perfetto -o /data/misc/perfetto-traces/trace_file.perfetto-trace -t 30s --buffer 2000mb gfx input view webview wm am sm audio video camera hal res dalvik rs power pm ss database network adb vibrator aidl nnapi rro sched irq i2c freq idle disk mmc sync workq memreclaim regulators binder_driver binder_lock pagecache memory thermal ion bionic perf pdx This can
capture 30s trace