Re: [PATCH 0/8] ASoC: SOF: power optimizations for HDaudio platforms

[Jaroslav Kysela <perex@perex.cz>]

On 11. 06. 21 9:58, Takashi Iwai wrote:
> On Thu, 10 Jun 2021 22:53:18 +0200,
> Pierre-Louis Bossart wrote:
>>
>> This patchset provides two optimizations that result in significant power
>> savings on Intel HDAudio platforms using SOF (Sound Open Firmware).
>>
>> a) We previously prevented the Intel DSP from enabling the DMI_L1
>> capability to work-around issues with pause on capture streams. It
>> turns out that this also prevented the platform from entering high C
>> states in full-duplex usages such as videoconferencing - a rather
>> basic use case since the start of the pandemic. The support for
>> pause_push/release was already a bit controversial for Intel
>> platforms, in theory platforms should only enable PAUSE if they can
>> resume on the same sample, which is not the case on any Intel
>> platform. Since we didn't want to disable a capability that could
>> impact existing users, the suggestion is to optionally disable
>> pause_push/release at build time or via a kernel parameter, in which
>> case DMI_L1 is enabled. In practice very few applications make use of
>> pause_push/release so there should be a limited impact when disabling
>> this ALSA capability.
>>
>> b) The use of the SPIB register also helps reduce power consumption,
>> though to a smaller degree than DMI_L1. This hardware capability is
>> however incompatible with userspace-initiated rewinds typically used
>> by PulseAudio. In the past (2015..2017) Intel suggested an API
>> extension to let applications disable rewinds. At the time the
>> feedback was that such a capability was too Intel-specific and SPIB
>> remained unused except for loading DSP code. We now see devices with
>> smaller batteries being released, and it's time to revisit Linux
>> support for SPIB to extend battery life. In this update the rewinds
>> are disabled either at build-time or via a kernel parameter. As
>> suggested by Takashi, a new SDNDRV_PCM_INFO flag is needed though to
>> make sure the appl_ptr value is provided to the driver through the
>> .ack callback. Distributions using PipeWire (Fedora34) and CRAS
>> (ChromeOS/Chromium) can safely enable this option. Distributions using
>> PulseAudio should probably avoid enabling it, although nothing is
>> really fundamentally broken if they do. While in theory volume updates
>> and mixing of notifications could be delayed, in practice
>> distributions use small ring buffers that make such delays difficult
>> to notice.
>>
>> Again both of these updates are opt-in to avoid any impact on existing
>> solutions or users: someone updating their kernel source but using
>> 'make olddefconfig' will see the same results. Distributions that care
>> neither about pause_push/release or rewinds should enable both
>> options, in case of issues users will still be able to override
>> these build-time choices with a simple module parameter.
> 
> Hmm, in general it's not easy for distros to decide which kconfig to
> take because most of distros ship both PulseAuadio and pipweire.
> It's rather the runtime choice, even different for each user at
> starting a different DE session, hence a kconfig or a module config
> doesn't fit well.
> 
> That said, it comes to the question about the severity of the change:
> how badly would behave if we disable the rewind?  If the influence is
> limited, distros can take it as a cost of the better power-saving
> (which is often preferred).  If PA's behavior change is significant,
> the option is way too dangerous, and it's hard to set as default.

I would prefer to add a new API which will tell that the rewind support
consumes more energy (is costly) and let apps to disable this feature when the
user agreed. We should create an universal API without any sound server /
application assumptions. We don't know beforehand, if users want the ultra low
latencies for a purpose or they want to save the battery power.

The same objection is for the pcm mmap control suppression / pause trigger
suppression.

The pulseaudio / pipewire code can be extended and it's better if both sides
(driver / apps) agree on the protocol.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.