Re: alsa-utils aplay/arecord can't be interrupted when streaming is not active

[jiwang <jiada_wang@mentor.com>]

Hi Jaroslav

On 04/16/2014 05:58 PM, Jaroslav Kysela wrote:
> Date 16.4.2014 10:34, jiwang wrote:
>> Hi Jaroslav
>>
>> On 04/16/2014 05:06 PM, Jaroslav Kysela wrote:
>>> Date 16.4.2014 09:54, jiwang wrote:
>>>> Hi All
>>>>
>>>> With latest 1.0.27.2 alsa-utils, I am facing problem to interrupt
>>>> aplay/arecord
>>>> when the streaming is not active (no data can be written to or read from
>>>> cards)
>>>> further more, if I start aplay/arecord with "-N" nonblocking option,
>>>> then aplay/arecord can never exit, unless I do a system reset
>>> If I/O stalls it's usually problem in the driver. You don't write any
>>> information about your configuration - post 'aplay -v' to see more.
>> This issue is caught when we were doing some tests,
>> test for both correct and incorrect configuration of driver
>> and we expect SIGINT can interrupt aplay/arecord in both cases
>> (which was the cause with the old version 1.0.26)
>>
>>> You may kill the process using the SIGABRT signal.. No reboot is required.
>> Yes, SIGABRT works,
>> But as in our case:
>> CPU dai device is waiting on a external clock,
>> but isnt provided caused the I/O stall
>> the driver is functioning properly and should still be SIGINT-ed in my
>> opinion
> The user space received SIGINT, but the current aplay code tries to
> finish the device close sequence. Could you determine, in which syscall
> is the process after you sent SIGINT? A backtrace would be great.
I am not sure if this is want you wanted
I got the following trace just after send SIGINT to blocking aplay

cat trace | tail -10
            aplay-648   [001] ...1  1677.882125: snd_pcm_sync_ptr 
<-snd_pcm_common_ioctl1
            aplay-648   [001] ...1  1677.882161: snd_pcm_playback_ioctl 
<-vfs_ioctl
            aplay-648   [001] ...1  1677.882162: snd_pcm_lib_write 
<-snd_pcm_playback_ioctl1
            aplay-648   [001] d..3  1677.882165: soc_pcm_pointer 
<-snd_pcm_update_hw_ptr0
            aplay-648   [001] d..3  1677.882167: 
snd_dmaengine_pcm_pointer_no_residue <-soc_pcm_pointer
           <idle>-0     [001] d.h4  1677.882321: fsl_esai_start_transmit 
<-tx_startup_timer_callback
            aplay-648   [000] ...1  1687.539380: snd_pcm_playback_ioctl 
<-vfs_ioctl
            aplay-648   [000] ...1  1687.539386: snd_pcm_lib_write 
<-snd_pcm_playback_ioctl1
            aplay-648   [000] d..3  1687.539391: soc_pcm_pointer 
<-snd_pcm_update_hw_ptr0
            aplay-648   [000] d..3  1687.539393: 
snd_dmaengine_pcm_pointer_no_residue <-soc_pcm_pointer

Thanks,
Jiada
>> Thanks,
>> Jiada
>>
>>>> I found if I revert the following patch
>>>>
>>>> /commit 1d0042d7e948815f8015c62bc53143eed3b83206//
>>>> //Author: Jaroslav Kysela <perex@perex.cz>//
>>>> //Date:   Mon Apr 8 13:30:54 2013 +0200//
>>>> //
>>>> //    aplay/arecord: change the interrupt handling using snd_pcm_abort()//
>>>> //    //
>>>> //    It is required (exclude the fatal SIGABRT) to call snd_pcm_close()
>>>> and//
>>>> //    the end of work (outside of the interrupt handler). Use new
>>>> snd_pcm_abort()//
>>>> //    function to inform alsa-lib to not ignore EINTR and move the
>>>> in_aborting//
>>>> //    variable to the global scope to be checked in the i/o loops.//
>>>> //    //
>>>> //    Signed-off-by: Jaroslav Kysela <perex@perex.cz>//
>>>> /
>>>> http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=1d0042d7e948815f8015c62bc53143eed3b83206
>>>>
>>>> then aplay/arecord can be interrupted correctly
>>>>
>>>> Is it a defect in aplay.c or did I miss something?
>>>>
>>>> Thanks,
>>>> Jiada
>>>>
>