I find it rather surprising simply playing a song on a contemporary #Linux desktop (e.g. Rhythmbox via #Pipewire via ALSA) increases baseline power consumption by nearly a Watt (on an AMD Framework 13), with rhythmbox, pipewire, and pipewire-pulse all waking up a 60 Hz using a combined 22 ms/s of CPU time.
While I'm only vaguely familiar with the Pipewire, it feels like it should be possible to do better for such a common task.
@bgamari It seems like by default pipewire streams are using very small buffer, with pw-top you can check what is the exchange rate. Perhaps it is possible to increase the size to reduce the load with PIPEWIRE_LATENCY?
@bgamari I observe the same locally with the sof-hda-dsp driver (2048 for the device, 3600 for firefox). It looks likes this could be set through /usr/share/wireplumber/wireplumber.conf.d/alsa-vm.conf, which mention api.alsa.headroom = 2048.
I am sorry this is not very helpful, I guess we are missing a powersaving profile for pipewire.
@bgamari I asked about this on the #pipewire matrix channel, and 2048 is the default value for clock.max-quantum, probably chosen as a point after which latency starts to be more noticeable.
The pipewire-pulse does cause an overhead, but I wonder what was the cost of pure pulseaudio versus ALSA or OSS, do you remember measuring the power consumption back then?
you know hacking kubernetes manifests is so much more comfortable in python... is there any drive to get a yaml processor into the python standard lib?
