On 11. 06. 21 16:32, Pierre-Louis Bossart wrote: > 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? Thinking more, my main objection is that we cannot change the runtime behaviour after the drivers are loaded in an easy way. I think that the current default settings should be kept without any Kconfig extensions. The module options are always good for the debugging, so they're fine in my eyes. I see the Takashi's arguments, too. Perhaps, it may be acceptable to add a global control enum (to the control API) for the ALSA card which may modify the driver behaviour / settings at runtime (normal operation, battery saving operation etc.). This control can be set in the UCM config. In this way, we don't need to touch the PCM API for the user space at all. Jaroslav -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
