On Tue, 04 Oct 2022 13:18:15 +0200, Daniel Baluta wrote: > > On Tue, Oct 4, 2022 at 12:46 PM Pierre-Louis Bossart > <pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote: > > > > On 10/4/22 11:07 AM, Daniel Baluta wrote: > > > Hello all, > > > > > > It looks like system suspend is not implemented for Compress streams. > > > > > > Any story behind this? Were there any attempts on implementing this? > > > > It depends on the definition of 'system suspend'. > > > > What we had in mind back in the early 2010s was to allow for 'active > > suspend' aka S0ix or low-power playback. That was the main reason for > > introducing the API. > > > > For suspend to S3/D3, the plan was to just completely stop any > > playback/capture and restart on resume. I am not sure if this was ever > > implemented, that may be a miss. > > I see. Yes, we are looking at S3/D3 suspend and this doesn't look to > be implemented. > > > > > There is a corner case we may have overlooked. I am not sure what > > happens if the S3/D3 suspend while playing. This is supported with e.g. > > aplay but for the compressed case it's a bit more complicated. Not all > > formats support rendering for a random position. > > True. We want to implement the same behavior as for aplay. Stop > any playback/capture and restart on resume. For PCM, basically the ALSA core doesn't fully "resume" unless the driver explicitly implements it. It merely stops (drops) the stream, sets the stream state to SNDRV_PCM_STATE_SUSPENDED, and lest the user-space re-prepare and restart. Each driver is supposed to call snd_pcm_suspend*() in the suspend callback, and basically that's all. I guess the same mechanism should be implemented for the compress stream, too. Takashi
