Takashi Iwai wrote: >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
doing a fresh checkout now, stay tuned. tim _______________________________________________________________ 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
