[Sound-open-firmware] The issue of XRUN happened in Kernel and PANIC in firmware
Hello All:
When we use the "aplay" tool to play the audio wave file, a XRUN (under-run) would happen.
It is high possibility on my APL-GPMRB platform (100%).
Which is detected by Linux kernel in snd_pcm_update_state() function.
This means the "hw_ptr" reaches "appl_ptr".
From the log, before XRUN happened, the "hw_ptr" is updated by DSP side (through the IPC) without any problem.
The "appl_ptr" is updated with about 8ms interval, but in some case, the "appl_ptr" is not updated in time.
The "appl_ptr" is updated by main thread (in __snd_pcm_lib_xfer() function).
Then the XRUN happens!
Below is the call-stack of the "aplay" tool. The *safe_read()* function reads the audio data into local buffer from wave file.
I add the timestamp log before and after this function. Usually the delta time should be very small (less than 1ms).
But sometimes, the safe_read() will take more than 50ms! Note: It reads the audio data successfully at last.
In this time, the underrun issue will be detected by kernel.
playback_go() *safe_read()* pcm_write() writei_func() snd_pcm_writei() _snd_pcm_writei() pcm->fast_ops->writei() snd_pcm_hw_writei() ioctl(fd, SNDRV_PCM_IOCTL_WRITEI_FRAMES, &xferi)
When the XRUN is detected by kernel, the recover process will start.
the kernel will send STOP command to DSP by IPC, then send the START command to DSP.
During the recover process, our DSP will hits panic!!! This possibility is very high on my platform (100%).
Summary:
1) From the dump data of the DSP(when panic happens),
DSP panic happened in the wait_for_completion_timeout() function.
When it is waken up by other interrupt (slept by waiti instruction), it hits crash when loading a data into register.
I checked there is no stack-overflow in this time.
I do not understand the log: Exception Cause: LoadStorePIFDataErrorCause, Synchronous PIF data error during LoadStore access.
Do you have any idea?
2) For the "aplay" tool's issue. the safe_read() function wastes too much time sometimes.
I have no idea how to debug this issue. or we should report this issue to any other team?
thanks
br
~zhigang
what is the alsa buffer size in your case? you can find it at the beginning if you run aplay with -vvv.
~Keyon
On 2018年06月13日 16:08, zhigangw wrote:
Hello All:
When we use the "aplay" tool to play the audio wave file, a XRUN (under-run) would happen.
It is high possibility on my APL-GPMRB platform (100%).
Which is detected by Linux kernel in snd_pcm_update_state() function.
This means the "hw_ptr" reaches "appl_ptr".
From the log, before XRUN happened, the "hw_ptr" is updated by DSP side (through the IPC) without any problem.
The "appl_ptr" is updated with about 8ms interval, but in some case, the "appl_ptr" is not updated in time.
The "appl_ptr" is updated by main thread (in __snd_pcm_lib_xfer() function).
Then the XRUN happens!
Below is the call-stack of the "aplay" tool. The *safe_read()* function reads the audio data into local buffer from wave file.
I add the timestamp log before and after this function. Usually the delta time should be very small (less than 1ms).
But sometimes, the safe_read() will take more than 50ms! Note: It reads the audio data successfully at last.
In this time, the underrun issue will be detected by kernel.
playback_go() *safe_read()* pcm_write() writei_func() snd_pcm_writei() _snd_pcm_writei() pcm->fast_ops->writei() snd_pcm_hw_writei() ioctl(fd, SNDRV_PCM_IOCTL_WRITEI_FRAMES, &xferi)
When the XRUN is detected by kernel, the recover process will start.
the kernel will send STOP command to DSP by IPC, then send the START command to DSP.
During the recover process, our DSP will hits panic!!! This possibility is very high on my platform (100%).
Summary:
1) From the dump data of the DSP(when panic happens),
DSP panic happened in the wait_for_completion_timeout() function.
When it is waken up by other interrupt (slept by waiti instruction), it hits crash when loading a data into register.
I checked there is no stack-overflow in this time.
I do not understand the log: Exception Cause: LoadStorePIFDataErrorCause, Synchronous PIF data error during LoadStore access.
Do you have any idea?
2) For the "aplay" tool's issue. the safe_read() function wastes too much time sometimes.
I have no idea how to debug this issue. or we should report this issue to any other team?
thanks
br
~zhigang
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 2018年06月13日 17:02, Keyon Jie wrote:
what is the alsa buffer size in your case? you can find it at the beginning if you run aplay with -vvv.
~Keyon
the buffer size is 1920 the period size is 384 I do this debug with TDM8-32bit-48kHz configuration and the wave is 8-channel-32bit file. It does not hit the crash at the beginning. please pay attention to this.
Thanks ~zhigang
On 2018年06月13日 16:08, zhigangw wrote:
Hello All:
When we use the "aplay" tool to play the audio wave file, a XRUN (under-run) would happen.
It is high possibility on my APL-GPMRB platform (100%).
Which is detected by Linux kernel in snd_pcm_update_state() function.
This means the "hw_ptr" reaches "appl_ptr".
From the log, before XRUN happened, the "hw_ptr" is updated by DSP side (through the IPC) without any problem.
The "appl_ptr" is updated with about 8ms interval, but in some case, the "appl_ptr" is not updated in time.
The "appl_ptr" is updated by main thread (in __snd_pcm_lib_xfer() function).
Then the XRUN happens!
Below is the call-stack of the "aplay" tool. The *safe_read()* function reads the audio data into local buffer from wave file.
I add the timestamp log before and after this function. Usually the delta time should be very small (less than 1ms).
But sometimes, the safe_read() will take more than 50ms! Note: It reads the audio data successfully at last.
In this time, the underrun issue will be detected by kernel.
playback_go() *safe_read()* pcm_write() writei_func() snd_pcm_writei() _snd_pcm_writei() pcm->fast_ops->writei() snd_pcm_hw_writei() ioctl(fd, SNDRV_PCM_IOCTL_WRITEI_FRAMES, &xferi)
When the XRUN is detected by kernel, the recover process will start.
the kernel will send STOP command to DSP by IPC, then send the START command to DSP.
During the recover process, our DSP will hits panic!!! This possibility is very high on my platform (100%).
Summary:
1) From the dump data of the DSP(when panic happens),
DSP panic happened in the wait_for_completion_timeout() function.
When it is waken up by other interrupt (slept by waiti instruction), it hits crash when loading a data into register.
I checked there is no stack-overflow in this time.
I do not understand the log: Exception Cause: LoadStorePIFDataErrorCause, Synchronous PIF data error during LoadStore access.
Do you have any idea?
2) For the "aplay" tool's issue. the safe_read() function wastes too much time sometimes.
I have no idea how to debug this issue. or we should report this issue to any other team?
thanks
br
~zhigang
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Wed, 2018-06-13 at 16:08 +0800, zhigangw wrote:
Hello All:
When we use the "aplay" tool to play the audio wave file, aXRUN (under-run) would happen.
It is high possibility on my APL-GPMRB platform (100%).
Which is detected by Linux kernel in snd_pcm_update_state() function.
This means the "hw_ptr" reaches "appl_ptr".
From the log, before XRUN happened, the "hw_ptr" is updated by DSP side (through the IPC) without any problem.
The "appl_ptr" is updated with about 8ms interval, but in some case, the "appl_ptr" is not updated in time.
The "appl_ptr" is updated by main thread (in __snd_pcm_lib_xfer() function).
Then the XRUN happens!
Below is the call-stack of the "aplay" tool. The *safe_read()* function reads the audio data into local buffer from wave file.
I add the timestamp log before and after this function. Usually the delta time should be very small (less than 1ms).
But sometimes, the safe_read() will take more than 50ms! Note: It reads the audio data successfully at last.
FS latency. Does this happen if you play /dev/zero ?
In this time, the underrun issue will be detected by kernel.
playback_go()*safe_read()* pcm_write() writei_func() snd_pcm_writei() _snd_pcm_writei() pcm->fast_ops->writei() snd_pcm_hw_writei() ioctl(fd, SNDRV_PCM_IOCTL_WRITEI_FRAMES, &xferi)
When the XRUN is detected by kernel, the recover process will start.
the kernel will send STOP command to DSP by IPC, then send the START command to DSP.
During the recover process, our DSP will hits panic!!! This possibility is very high on my platform (100%).
This panic is a separate issue.
Summary:
1) From the dump data of the DSP(when panic happens), DSP panic happened in the wait_for_completion_timeout() function. When it is waken up by other interrupt (slept by waitiinstruction), it hits crash when loading a data into register.
I checked there is no stack-overflow in this time. I do not understand the log: Exception Cause:LoadStorePIFDataErrorCause, Synchronous PIF data error during LoadStore access.
Do you have any idea?
This means you are doing IO with non existent memory region. Check your pointers.
Liam
2) For the "aplay" tool's issue. the safe_read() function wastestoo much time sometimes.
I have no idea how to debug this issue. or we should reportthis issue to any other team?
thanks
br
~zhigang
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
participants (3)
-
Keyon Jie -
Liam Girdwood -
zhigangw