> 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. 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? Thanks, Ranjani _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
