Disabling uclamp on demand / by user config

[marcan]

The uclamp config works well for high buffer sizes using the internal speakers/mic. It doesn't once you start using other audio I/O devices, more complex graphs, and lower buffer sizes.

We need some way to disable the uclamp config. Ideally it should be something tunable at runtime that automatically tells all components (pipewire, wireplumber, pipewire-pulse) to switch off uclamp.

For autoconfig, one possible trivial signal to use would be whether there is any audio device configured with the Pro Audio profile which is active.

For a first shot, there should be some documented way to override the Asahi uclamp config with user configs. Right now I'm not sure if this is possible at all without touching system config files. I've been using uclampset at runtime but that's a hack.

[chadmed]

Apart from not being possible to do without interrupting audio streams, what is fundamentally wrong with just editing the config files and restarting the daemons? It's the correct way to do it as far as upstream is concerned, and ensures that the config persists as required across login sessions.

There is currently no mechanism to modify a PipeWire module's state at runtime. The only way we would be able to achieve in-place uclamp changes at runtime without building that mechanism ourselves would be to wrap uclampset in a shell script or something that grabs the PIDs of the three main WirePlumber and PipeWire processes. Happy to do it if we really want it, but not sure this falls under the remit of Asahi specifically per se.

[marcan]

You can't override 99-asahi.conf without clobbering system config files. PipeWire simply skips identically-named files in ~/.config/pipewire/pipewire.conf.d. If you instead use a different file, it's parsed after the system configs and merely adds a new module instance of libpipewire-module-rt, but does not override the existing one and most of the PipeWire threads still end up with the Asahi uclamp.

I don't intend to say this should be implemented in asahi-audio, rather I expect this will need PipeWire changes most likely. I'm just filing it here as the top-level issue.