me wrote:
>Takashi Iwai wrote:
>
>>At Thu, 30 May 2002 17:14:03 +0200 (CEST),
>>Tim Goetze wrote:
>>>
>>> hi all,
>>>
>>> both emu8k and ice1712 pcm drivers hang forever in ioctl(2) when
>>> closing a playback stream if the stream has been linked to the
>>> same card's capture, has been prepared and written data to, but was
>>> never started:
>>>
>>> Program received signal SIGINT, Interrupt.
>>> 0x403b8fa4 in ioctl () from /lib/libc.so.6
>>> (gdb) bt
>>> #0 0x403b8fa4 in ioctl () from /lib/libc.so.6
>>> #1 0x40580abc in __DTOR_END__ () from /usr/lib/libasound.so.2
>>> #2 0x4053bde9 in snd_pcm_drain (pcm=0x81c6ae8) at pcm.c:813
>>> #3 0x4053b649 in snd_pcm_close (pcm=0x81c6ae8) at pcm.c:552
>>> #4 0x40462d79 in AlsaStream::~AlsaStream (this=0x81bf6a8,
>>> __in_chrg=0)
>>> at AlsaStream.cc:41
>>> #5 0x4049ef01 in AlsaOut::~AlsaOut (this=0x81bf6a8, __in_chrg=3)
>>> at PyType.h:110
>>
>>it seems stalling at drain ioctl. can you figure out which stream is?
>
>playback.
a playback stream not linked to any other stream behaves the same.
before calling snd_pcm_close(), i get
[~] cat /proc/asound/ice/pcm0p/sub0/status
state: PREPARED
trigger_time: 0.000000
tstamp : 1022886544.305384
delay : -1053620964
avail : 0
avail_max : 0
this is what happens in snd_pcm_playback_drain() when i call
snd_pcm_close() now:
the stream is started ok. the stream state is then switched to
SNDRV_PCM_STATE_DRAINING and then the interruptible loop waiting for
the stream to go to a different state is running forever because
stream->state remains 5 = SNDRV_PCM_STATE_DRAINING.
at this point, i get
[~] cat /proc/asound/ice/pcm0p/sub0/status
state: <NULL>
trigger_time: 1022886587.196499
tstamp : 1022886605.224624
delay : -790953
avail : 795049
avail_max : 795049
and a little later
[~] cat /proc/asound/ice/pcm0p/sub0/status
state: <NULL>
trigger_time: 1022886587.196499
tstamp : 1022886607.877699
delay : -907955
avail : 912051
avail_max : 912051
and so on, so the card is firing irqs (a fact cat /proc/interrupts
confirms).
if i haven't run my code under gdb i then need to reboot the box to
work with the card because the module is claimed 'busy'.
tim
ps: i think "state: <NULL>" in the output from /proc above suggests
that "char * snd_pcm_state_names[]" (in kernel/pcm.c:139) needs a
revision. a patch is attached.
pps: please, please, please somebody of you authors of alsa-driver/*,
do add some comments around the code. i have absolutely no clue why
a stream that is about to be closed needs draining in the first place.
Index: alsa-driver/kernel/pcm.c
===================================================================
RCS file: /cvsroot/alsa/alsa-driver/kernel/Attic/pcm.c,v
retrieving revision 1.120
diff -u -r1.120 pcm.c
--- alsa-driver/kernel/pcm.c 12 Oct 2001 10:43:18 -0000 1.120
+++ alsa-driver/kernel/pcm.c 31 May 2002 23:45:54 -0000
@@ -141,7 +141,9 @@
STATE(PREPARED),
STATE(RUNNING),
STATE(XRUN),
+ STATE(DRAINING),
STATE(PAUSED),
+ STATE(SUSPENDED),
};
char *snd_pcm_access_names[] = {
