On Wed, 21 Jun 2017 19:58:24 +0200, bgoswami@xxxxxxxxxxxxxx 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
