ALSA Compress API - system suspend/resume
Hello all,
It looks like system suspend is not implemented for Compress streams.
Any story behind this? Were there any attempts on implementing this?
thanks, Daniel.
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.
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.
On Tue, Oct 4, 2022 at 12:46 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com 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.
Thanks!
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@linux.intel.com 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
On 04-10-22, 13:58, Takashi Iwai wrote:
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@linux.intel.com 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.
There has been discussion in the past for this and as Pierre commented above it is really hard to resume a compressed stream. There is a big DSP dependency here..
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.
Agree, based on DSP support a driver can opt in. Userspace should send the data as expected after resume. I dont think we can ever continue but it should be possible to restore at next frame or previous frame ...
participants (4)
-
Daniel Baluta -
Pierre-Louis Bossart -
Takashi Iwai -
Vinod Koul