[alsa-devel] Query regarding possibility of PM QoS unvote/vote when substream Pause/Resume called

[Takashi Iwai]

On Wed, 21 Jun 2017 19:58:24 +0200,
bgoswami at codeaurora.org wrote:
> 
> Hi,
> 
>   Current ALSA core implementation has PM QoS vote/unvote calls in
> snd_pcm_hw_params() and snd_pcm_hw_free().
> 
>  However, this might have an implication in terms of power, as PM QoS
> vote would still be valid for that substream, even when the substream
> is paused. Especially for those cases, where, to avoid missing the
> QoS, one or more CPU cores might be prevented from entering into lower
> power mode (or power-collapse), as it might take longer to bring those
> cores out of power collapse. This might be specially more prominent
> when the period size is smaller.
> 
>   So, in an effort to optimize power (by whatever smaller amount), I
> was wondering, if it is better to remove the PM QoS vote
> (pm_qos_remove_request) when Pause (SNDRV_PCM_TRIGGER_PAUSE_PUSH) is
> called from user space (using IOCTL) for a particular substream.
>  Similarly, PM QoS vote can be added (pm_qos_add_request) back, when
> user space (using IOCTL) calls Resume
> (SNDRV_PCM_TRIGGER_PAUSE_RELEASE) for that same substream.

It's a good question.  The current calls in hw_params and hw_free with
a naive assumption about the usage pattern.

>  I am looking for opinions from subject matter experts, to see if the
> proposed approach might have any unintended side-effects or any known
> limitation that I might be missing.

I don't see a bit side effect, but I'd like to look at the real gain
by such a chain.  Could you test and measure?  If we can see a
significant difference, we should try harder to narrow the window,
indeed.


thanks,

Takashi