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
