[Sound-open-firmware] The issue of XRUN happened in Kernel and PANIC in firmware

[zhigangw]

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 at alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware