Re: Issue in pcm_dsnoop.c in alsa-lib

[Takashi Iwai <tiwai@suse.de>]

On Tue, 01 Mar 2022 05:16:38 +0100,
Shengjiu Wang wrote:
> 
> Hi Takashi Iwai, Jaroslav Kysela
> 
>     We encountered an issue in the pcm_dsnoop use case, could you please
> help to have a look?
> 
>     *Issue description:*
>     With two instances for dsnoop type device running in parallel, after
> suspend/resume,  one of the instances will be hung in memcpy because the
> very large copy size is obtained.
> 
> #3 0x0000ffffa78d5098 in snd_pcm_dsnoop_sync_ptr (pcm=0xaaab06563da0)
> at pcm_dsnoop.c:158
> dsnoop = 0xaaab06563c20
> slave_hw_ptr = 64
> old_slave_hw_ptr = 533120
> avail = *187651522444320*
> 
>   * Reason analysis: *
>    The root cause that I analysis is that after suspend/resume,  one
> instance will get the SND_PCM_STATE_SUSPENDED state from slave pcm device,
>   then it will do snd_pcm_prepare() and snd_pcm_start(),  which will reset
> the dsnoop->slave_hw_ptr and the hw_ptr of slave pcm device,  then the
> state of this instance is correct.  But another instance may not get
> the SND_PCM_STATE_SUSPENDED state from slave pcm device because slave
> device may have been recovered by first instance,  so
> the dsnoop->slave_hw_ptr is not reset.  but because hw_ptr of slave pcm
> device has been reset,  so there will be a very large "avail" size.
> 
>    *Solution:*
>    I didn't come up with a fix for this issue,  seems there is no easy way
> to let another instance know this case and reset the
> dsnoop->slave_hw_ptr,  could you please help?

Could you try topic/pcm-direct-resume branch on
  https://github.com/tiwai/alsa-lib

??


thanks,

Takashi