Hi Takashi,
Thanks for your reply and suggestions. Finally we have found the root cause.
Seems it's related to both drivers and alsa-lib.
When two dmix clients run in parallel we get two direct dmix instances.
1st dmix instance:
snd_pcm_dmix_open()
snd_pcm_direct_initialize_slave()
save_slave_setting()
Since the driver we are using has SND_PCM_INFO_RESUME flag, dmix->spcm->info
has this flag. Then this flag is cleared in dmix->shmptr->s.info.
2nd dmix instance:
snd_pcm_dmix_open()
snd_pcm_direct_open_secondary_client()
copy_slave_setting()
2nd dmix->spcm->info is copied from dmix->shmptr->s.info so it doesn' has this
flag.
If 1st dmix instance resumes firstly it should implement recovery of slave pcm
in snd_pcm_direct_slave_recover(). Because 1st dmix->spcm->info has
SND_PCM_INFO_RESUME，snd_pcm_resume(direct->spcm) can be called correctly to
resume slave pcm.
However if 2nd dmix instance resumes firstly, snd_pcm_resume(direct->spcm) will
not be called because it's spcm->info doesn't has SND_PCM_INFO_RESUME flag. The
1st dmix instance assumes someone else already did recovery so
snd_pcm_resume(direct->spcm) won't be called neither. In result the slave pcm
fails to resume.
SND_PCM_INFO_RESUME flag has impact on the flow of dmix resume. In my opinion
the first resumed dmix instance should make sure slave pcm can be recovered
properly no matter it's the first opened instance or secondary opened instance.
Do you know why the secondary opened instance clear the SND_PCM_INFO_RESUME
flag? Can we do the following modification?
diff --git a/src/pcm/pcm_direct.c b/src/pcm/pcm_direct.c
@@ -1183,8 +1226,6 @@ static void save_slave_setting(snd_pcm_direct_t *dmix, snd_pcm_t *spcm)
COPY_SLAVE(buffer_time);
COPY_SLAVE(sample_bits);
COPY_SLAVE(frame_bits);
-
- dmix->shmptr->s.info &= ~SND_PCM_INFO_RESUME;
Regards,
Chancel Liu
> [ 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
