Re: Suspend/resume Issue on pcm_dmix.c in alsa-lib

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