[ it seems that my previous post didn't go out properly, so resent; if you've seen already the same, please disregard ] On Tue, 27 Aug 2024 09:06:39 +0200, Chancel Liu wrote: > > > Hi Takashi Iwai, Jaroslav Kysela > > We found an issue on dmix in alsa-lib when do suspend and resume. It can be > easily reproduced by following steps: > > 1. Run two dmix clients in parallel. (Only one client doesnʼt has such issue) > > ~# aplay xxx1.wav & > > ~# aplay xxx2.wav & > > Here I attach the asound.conf we're using. > > ~# cat /etc/asound.conf > > defaults.pcm.rate_converter "linear" > > pcm.dmix_44100{ > > type dmix > > ipc_key 5678293 > > ipc_key_add_uid yes > > slave{ > > pcm "hw:0,0" > > period_time 40000 > > format S16_LE > > rate 44100 > > } > > } > > pcm.asymed{ > > type asym > > playback.pcm "dmix_44100" > > capture.pcm "dsnoop_44100" > > } > > pcm.!default{ > > type plug > > route_policy "average" > > slave.pcm "asymed" > > } > > 2. Let linux enter into suspend and then resume(Repeat this step if not > reproduced) > > 3. After resume, aplay will get stuck in snd_pcm_wait(). The GDB shows: > > (gdb) bt > > #0 0x0000fffff7da9264 in __GI___poll (fds=fds@entry=0xfffffffff480, nfds= > nfds@entry=1, timeout=timeout@entry=240) > > at /usr/src/debug/glibc/2.39+git/sysdeps/unix/sysv/linux/poll.c:41 > > #1 0x0000fffff7edf468 in poll (__timeout=240, __nfds=1, __fds=0xfffffffff480) > > #2 snd1_pcm_wait_nocheck (pcm=pcm@entry=0xaaaaaaad2cb0, timeout=240, > timeout@entry=-10001) at pcm.c:2993 > > #3 0x0000fffff7ee54a0 in snd1_pcm_write_areas (pcm=pcm@entry=0xaaaaaaad2cb0, > areas=areas@entry=0xfffffffff560, offset=<optimized out>, offset@entry=0, size > =<optimized out>, > > size@entry=1768, func=func@entry=0xfffff7ef5190 > <snd_pcm_plugin_write_areas>) at pcm.c:7699 > > #4 0x0000fffff7ef5020 in snd_pcm_plugin_writei (pcm=0xaaaaaaad2cb0, buffer= > <optimized out>, size=1768) at pcm_plugin.c:354 > > It seems that sometimes after suspend and resume there's no available space > for data written into buffer. Then aplay keeps stuck in snd_pcm_wait(). I > checked the hw_ptr of dmix and found that hw_ptr is always 0 after resume. > > I don't have a solution now so I turn to you for help. The version of alsa-lib > is v1.2.11. Could you please help check it? I tried your setup but I couldn't reproduce the issue locally with my laptop and HD-audio device. Possibly depending on the kernel driver? In the case of dmix, it's a poll() against the PCM slave timer. So it doesn't take care of suspend/resume state unlike the real PCM device. OTOH, the timer device should send notification events at suspend/resume, and it should trigger the poll wakeup, too. Does poll() return after the suspend/resume once but falls into a loop due to revents being unset? Or it's stuck and never returns at suspend/resume? thanks, Takashi