At Sat, 1 Jun 2002 01:49:00 +0200 (CEST),
Tim Goetze wrote:
>
> 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
hmm, delay value is bogus, but it's a minor bug of the driver.
should be zero cleared there.
> 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
apparently the avail value is incorrect.
is the buffer_size set to 4096?
> 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'.
hmm, it sounds like a similar problem i fixed once ago...
(although in my case it didn't fire up irqs).
>
> 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.
strange, this has to be fixed already.
and the filename in the patch you attached seems invalid.
could you check whether all the sources are updated?
the latest versions are:
alsa-kernel/core/pcm.c rcs rev. 1.12
alsa-kernel/core/pcm_nativ.c rcs rev. 1.13
alsa-kernel/core/pcm_lib.c rcs rev. 1.12
Takashi
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
