[ 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:
- 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"
}
- Let linux enter into suspend and then resume(Repeat this step if not
reproduced)
- 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