Re: [PATCH V2] ASoC: soc-pcm: BE dai needs prepare when pause release after resume

[Takashi Iwai <tiwai@suse.de>]

On Thu, 09 May 2019 18:56:12 +0200,
Ranjani Sridharan wrote:
> 
> > Hm, it's a good question.  Currently the PCM core doesn't care about
> > the paused stream wrt PM by the assumption that the paused / stopped
> > stream doesn't need a special resume treatment.  But, generally
> > speaking, the pause-release won't work for a hardware that doesn't
> > support the full resume, either.  For example, the legacy HD-audio
> > may
> > restart from some wrong position if resumed from the pause.
> > 
> > Maybe this problem hasn't been seen just because the pause function
> > is
> > rarely used.
> > 
> > So, the safe behavior would be to let the stream being SUSPENDED
> > state
> > at snd_pcm_stream_suspend() when it's in the PAUSED and has no
> > INFO_RESUME capability.  Then the application does re-prepare the
> > stream like the running one.
> > 
> > But the question is what's expected at next.  Should the application
> > re-start?  But it was paused.  Should PCM core automatically move to
> > pause?  But most hardware can't move the pointer to any random
> > position.
> > 
> > My gut feeling is just to treat like a normal error-restart,
> > i.e. re-prepare / re-start.  But I'm open and would like to hear more
> > opinions.
> 
> Hi Takashi,
> 
> So in the current scenario what we see is that after resuming from S3,
> a pause-release action from the user results in a FE prepare() followed
> by the START trigger (and not a PAUSE-RELEASE trigger).
> 
> Libin's patch proposes to do a prepare() for the BE even in the case of
> a regular pause-release. But this might not be ideal since other
> drivers might have logic in the prepare() ioctl that might end up with
> errors. 

Right.

> So I am thinking maybe we can have some internal logic in the SOF
> prepare() callback that will also call the BE prepare() when the 
> be->dpcm[stream].state is SND_SOC_DPCM_STATE_PAUSED? Would that make
> sense?

Yes, that would work, I guess.  Eventually this might be needed to be
addressed in ALSA core side, too, but it's good to have some fix
beforehand in DPCM.


thanks,

Takashi