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@xxxxxxx/
"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).
