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

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

Thanks Takashi and Jaroslav for your feedback

>> 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've personally tried mucking with PulseAudio and didn't see any side 
effects. We do know that by design the effects of rewinds become 
significant if the HDAudio ring buffer becomes large (e.g 0.5..2s), but 
most distros keep the default size.

> 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.

When I suggested an API extension (initial code in 2015) precisely to 
establish a 'contract' between userspace and driver, the answer from 
Takashi was this:

https://lore.kernel.org/alsa-devel/s5ha7uq7icw.wl-tiwai@suse.de/

"let's begin with the driver-specific implementation, and extend to API 
level once when we see what are the real demands in wide range of hardware."

What I am suggesting here is precisely the driver-specific implementation.

If both of you now prefer an API extension that's fine with me, that's 
what I preferred all along :-)

It's no big deal to bolt a userspace choice on top of those changes, but 
maybe we can do this as a second step?

I can remove the kconfig changes and only add kernel parameters in the 
mean time so that only early adopters make that selection. In a second 
step, these kernel parameters can be removed when applications make use 
of the new API extension.

Would this work for you?

I just want to stress that both of these changes result in significant 
power savings on Intel platforms. The world has changed since 2015 and 
the push to smaller batteries/longer battery life makes both of these 
changes very desirable. It's no longer an architecture-driven effort to 
enable new features, it's backed by real-world measurements on customer 
devices (which I can only disclose under NDA and not on a public mailing 
list obviously).