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