[WIP] pkgs: pulseaudio -> pressureaudio; nixos: override when running a daemon

[oxij]

Motivation for this change

An idea that struck me when writing #35292 (comment) (see #35355 (comment) for in-depth explanation of the motivation behind every part of that comment).

With this we link against pressureaudio by default to provide libpulse API over pure ALSA to apps that refuse to properly work over ALSA themselves (e.g. Firefox).

NixOS then overrides this with pulseaudioLib via LD_LIBRARY_PATH when user enables the daemon service (pressureaudio and pulseaudioLib are link-time-compatible).

This way users that don't run PulseAudio daemon and don't want to link against pulseaudioLib for religious and/or security reasons don't need to make any overrides, while PulseAudio daemon users stay happy.

This also significantly reduces closure size when not running PulseAudio daemon since pressureaudio (apulse) is tiny in comparison to pulseaudioLib and requires only alsaLib and glib.

It is a mass rebuild, but none of my PRs to staging got merged this month, so.

Things not done

• Not tested with hardware.pulseaudio.enable set. I refuse to set it for ethical reasons. But the change seems trivial enough that it should work.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of some pkgs that depend on this change using nix-shell -p nox --run "nox-review wip" Seems to work.
• Tested execution of many binary files of the changed packages. Seem to work.
• Fits CONTRIBUTING.md.

---

[oxij]

@GrahamcOfBorg Hooray!

I wonder what gets rebuilt on darwin. Is pulseaudio even supposed to work on darwin?

[oxij]

Ah. It's all those packages that do `config.pulseaudio or true` instead of `config.pulseaudio or stdenv.isLinux`.

[oxij]

I've set config.pulseaudio = true in my config, all that's left is to rebuild everything and see what will happen when the whole system uses fake pulseaudio.

[vcunat]

System-wide LD_LIBRARY_PATH turned out to be a fragile approach, IMHO, and we'd like to get rid of it for OpenGL. I wouldn't go this way.

[oxij]

System-wide `LD_LIBRARY_PATH` turned out to be a fragile approach, IMHO, and we'd like to get rid of it for OpenGL.

And replace it with what? Whatever you replace it with, this can use the same mechanism. I think most of `config.pulseaudio` patches from this branch should be squashed and merged into master with some cleanups (will do later). As to the general idea, it works well, but the whole thing together doesn't work as well as I want because many apps start using `apulse` instead of pure ALSA, which is tolerable, but is not what I want. I'm working on a better thing ATM.

[vcunat]

Probably replace it with glvnd, as that provides indirection to load the right libGL anyway. (We may still need some custom hacks, e.g. to find libGL on non-nixos, etc.)

[oxij]

I can see the reasoning behind glvnd - you can have multiple screens and LD_LIBRARY_PATH is not per-screen. Note, however, that we will still need an out-of-band way to provide vendor libGLs to glvnd (or else setting it up will cause only-for-your-system mass-rebuild, so no determinism added here) and it will still do the same thing internally (I mean, all it does is just dynamically links those functions). What is the reasoning behind your argument against this? You can't run two PulseAudio daemons at the same time. Also not that GL and this PR are not the two users of the mechanism. "sane" module in NixOS does this for the same reason.

[7c6f434c]

I think the problem with LD_LIBRARY_PATH is that some programs randomly decide to change this variable in a weird way but expect that they will still be able to find all the system libraries including libGL. Special-case side-channel variables are much less likely to be manipulated.

[oxij]

That was discussed at length in #31263. I'm not aware of any counterarguments to my arguments there. In short: most things have to be fixed anyway. Things that can't be fixed can be hacked around with simple ld hacks like always appending some static paths to the end of LD_LIBRARY_PATH in ld itself or adding them to /etc/ld-nix.so.cache.

[7c6f434c]

I think Steam alone disproves the numerical bound you give.

I mean, if no one would want to either write or use garbage software, we wouldn't have the current discussion.

Also. there are setuid applications.

[oxij]

Well, okay, point taken. However, in any case, that discussion is orthogonal to this discussion. Any solution applicable there can be transferred here. As long as there's no solution there I would prefer to solve problems one at a time.

[oxij]

Status report.

As I said in #35292 (comment)

Something very related I made: https://github.com/oxij/libcardiacarrest
It describes the problems with PulseAudio in some detail (including direct pointers at the crazy code in the lib) and provides what seems to be a working solution for all of this shit.
Will switch #35374 to using that after I come back to my senses from making the thing.

I switched this to libcardiacarrest and now rebuilding everything the nth time for libcardiacarrest v4+. On my laptop I'm running on v2 without any problems after applying patches from #36377, so it is very usable approach. But some apps do some crazy shit with PA API and fail to check for errors, so I had to fix some and add more PA shit to libcardiacarrest to fix others.

On v4 even official freedesktop PA tools gracefully fail as they should, so it's time to get excited. Will publish after I confirm Xfce and KDE work.

[oxij]

Status: Done. See #36881 for the version with libcardiacarrest instead of libpressureaudio. Keeping this open till that gets merged (also to remind myself to PR the rest of the changes here eventually).

[lukateras]

Can this be closed in favor of #36881?

[oxij]

I think most changes here are useful irrespective of #36881, but I'm a bit burned out on the issue to rebase them ATM.

[flokli]

Closing, due to the same reasons as expressed in #36881 (comment).

This is a controversial change, and needs to go through an RFC.

Keeping this PR open doesn't really help, it has bitrotten and doesn't apply cleanly anyhow.