* Re: alsa-utils aplay/arecord can't be interrupted when streaming is not active
2014-04-16 8:58 ` Jaroslav Kysela
@ 2014-04-16 12:00 ` Jiada Wang
2014-04-17 9:03 ` jiwang
2014-04-21 3:01 ` Jiada Wang
2 siblings, 0 replies; 7+ messages in thread
From: Jiada Wang @ 2014-04-16 12:00 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development
Hi Jaroslav
On 04/16/2014 01:58 AM, 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.
>
Currently I don't have access to board,
if I recall correctly
when aplay/arecord work in blocking mode
aplay is at:
pcm_write
--> writei_func(handle, data, count);
arecord is at:
pcm_read
--> readi_func(handle, data, count);
when aplay/arecord work in nonblocking mode
aplay is looping at
pcm_write
--> while (count > 0) { ... }
arecord is looping at
pcm_read
--> while (count > 0) { ... }
I will check it again when I have access to my board tomorrow
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
>>>>
>>>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: alsa-utils aplay/arecord can't be interrupted when streaming is not active
2014-04-16 8:58 ` Jaroslav Kysela
2014-04-16 12:00 ` Jiada Wang
@ 2014-04-17 9:03 ` jiwang
2014-04-21 3:01 ` Jiada Wang
2 siblings, 0 replies; 7+ messages in thread
From: jiwang @ 2014-04-17 9:03 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development
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
>>>>
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: alsa-utils aplay/arecord can't be interrupted when streaming is not active
2014-04-16 8:58 ` Jaroslav Kysela
2014-04-16 12:00 ` Jiada Wang
2014-04-17 9:03 ` jiwang
@ 2014-04-21 3:01 ` Jiada Wang
2 siblings, 0 replies; 7+ messages in thread
From: Jiada Wang @ 2014-04-21 3:01 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development
Hi Jaroslva
On 04/16/2014 01:58 AM, 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.
>
Do you have any update on this?
is more log required? do you think it should be fixed in aplay?
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
>>>>
>>>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread