[Request For Testing] pkgs: libpulseaudio -> libcardiacarrest; nixos: override when running PA daemon #36881
Conversation
GrahamcOfBorg
added
6.topic: nixos
|
This should probably go through an RFC first |
… PA daemon This satisfies both people that want to purge every single bit of PulseAudio from their systems for ethical, religious, and/or security reasons and those who want to run the daemon for convenience reasons. This also significantly reduces closure size when not running PulseAudio daemon since `libcardiacarrest` is tiny. NOTE: With this in place I - built everything I use, Xfce, KDE, most of GNOME3, - tested everything I use, Xfce, KDE, official PulseAudio tools like pavucontrol, etc, - verified that some other things I don't want to build (like Chromium) would work with this by looking at their sources, and everything seems to work (i.e. gracefully fails to use PulseAudio). However, I'm almost sure this will break things I didn't build and test. PulseAudio API is huge and full of surprises, hence many application authors fail use it correctly (and they are not alone, even the likes of Mozilla fail to properly check for PA errors in Firefox). If this commit breaks your thing, please, don't just revert this, instead override `libpulseaudio` for your thing with `libpulseaudio-vanilla` and then let me know about it so that I could fix an "ignores return values" bug in your thing or add some missing pieces to `libcardiacarrest` to make your thing happy. Thank you.
oxij
force-pushed
the
pkgs/the-cardiacarrest
branch
from
baa7667 to
7a29afd
Compare
oxij
changed the title
|
Well, I can copy-paste the OP into an RFC, but what is the point? It is a running code you can test already. No work except testing this needs to be done, really. I did all of it already. There's no real downsides to merging this (see the OP). And there's also not much of any kind of "design" involved anywhere. All this does, really, is it just replaces the |
|
My chief complaint is this PR is it is setting a general policy and direction for NixOS, and causing us to take a particular stance. It is not the code at issue here -- it is the roadmap-setting-disguised-as-code. |
|
@grahamc While I agree that your efforts to get processes working in Nix* are valuable and more succesful than can be believed, I am not sure we already have an RFC process that produces outcomes — any outcomes. |
|
Several points (disclosure: I use PulseAudio and see merits in it for a desktop user but want to keep both sides happy -- let's keep topic of whether to use it elsewhere).
|
|
I wonder how much the closure size benefit is actually rebuild frequency benefit — it is hard to meaningfully reduce the closure size of LibreOffice, Chromium or Wine, but reducing their rebuild frequency could be more feasible (and PA separation probably does remove some of the dependencies even from Chromium) |
|
This isn't about enforcing policy, but this is setting a policy. The default configuration expresses default policies and positions of the Nixpkgs community and group:
Changing
By the same token of not enforcing policy, users that don't run PulseAudio daemon and don't want to even link against To be clear, I'm a strong 👎 on this change and similar attempts to change our currently PulseAudio-supportive policy without an explicit move by the community to accept this as a goal. |
|
@grahamc, let me remind you that I have no intention of offending you (or anyone else).
Firstly, even if you do not mean it, you do push NixOS in some general policy and direction with every PR that makes some non-leaf changes you merge.
Were not #35292 and #35355 trying to set a general policy and direction? Did they go through an RFC process?
#35355 got merged while the whole PA thing was on a salty wave, then the `stateVersion` part of it was completely reverted, and the end result is that all NixOS users now simply have non-persistent ALSA settings by default. All of that to save users from installing 2 Megs of tools most of them would install anyway? Shouldn't that have gone through an RFC process too?
Secondly, I see no reason to even have Nixpkgs RFCs, Nixpkgs is not a programming language or networking protocol. Nixpkgs has documentation and git-log where you can document decisions. Those sources should be the primary sources. It's a software project, not a "blueprint" type of project. What is left of RFCs (those that produce interest and get eyes, that is) consists of comments, the actual text of an RFC doesn't matter that much because it's not the actual implementation. You can get the same process on top of normal NixOS PRs/issues/ML by asking people to stay on topic.
I do agree that RFCs have their use. "Do your research first" policy is a good policy and RFCs can be a good way to force people adhere to it. Another, IMHO simpler and better way to archive the same is to force people to provide references for their NixOS PRs and forcefully close PRs that don't have enough research.
Thirdly, I'd like to hear technical arguments against this. "Please make an RFC" sounds like "let's stall this forever" to me. Sorry. Unless you revert all of #35355 and make an RFC for the direction it was pushing in, I don't think that's fair. Sorry.
Btw, vanilla `libpulseaudio` (if you ignore all unique deps it carries into closure with it) libs are almost exactly the same size as all ALSA tools combined. Meanwhile, `libcardiacarrest` is 84K. Just sayin~
|
|
| @@ -228,6 +228,9 @@ in { | |||
| source = writeText "libao.conf" "default_driver=pulse"; } | |||
| ]; | |||
|
|
|||
| environment.sessionVariables.LD_LIBRARY_PATH = | |||
| [ "${getLib overriddenPackage}/lib" ]; | |||
There was a problem hiding this comment.
I don't think using LD_LIBRARY_PATH is a good idea for achieving this. In systemd jobs and when the environment gets cleared/filtered (like with sudo), LD_LIBRARY_PATH won't be inherited and has to be set manually.
Have you explored a solution like mesa-drivers in /run/opengl-drivers? The problem with that approach is that NixOS will be needed for PA-based applications. Maybe the RUNPATH can be patched so they will fall back to libcardiacarrest?
|
* @oxij Do I understand correctly the usual behavior of software you've tested was to fall back to ALSA when PulseAudio is not available?
Yes. All software I tested does this. Some (e.g. cmus) then caches the result and doesn't retry the second time you start it. But it's not a problem, since this doesn't break anything for such use case too.
Does it try to start it by itself if not started when using `libpulseaudio`?
Yes, unless the app specifically says "don't try to start it" to the lib.
If not then PulseAudio's code isn't actually used much by applications when the daemon is not started and so the main benefits are closure size and sanity checks for applications, which I'm not sure worth `LD_LIBRARY_PATH` (see below);
Also, that's not the only thing it does. See https://github.com/oxij/libcardiacarrest/blob/master/README.org. I seriously doubt you would still use PA after reading its sources.
* The PR itself won't work with multilib applications (easily fixed).
Do you mean I need to put `/lib32` in there somewhere?
This would also break FHS environments because they don't inherit host's `LD_LIBRARY_PATH` (for a good reason -- filesystem hierarchy is totally different, it's dangerous to do).
For them you can simply shove libs to where they belong in FHS environments.
Finally (and most seriously, I'm not sure we can fix that at all for this PR) this would break PulseAudio for non-NixOS (just Nix) use cases.
Well, not exactly. It does need some env hackery, though. Correct.
|
|
@grahamc Hm, I see your point -- my understanding was only correct given that PulseAudio isn't started by apps when it's not available and this isn't the case as @oxij pointed out so it's a change of behavior. I don't have a strong opinion on whether we want this behavior (I'd probably not and this seems counter-intuitive to me but someone may rely on it).
No, rather you'll need to put
The problem is that whether to enable PulseAudio is a system-wide decision and FHS environment is a package so we'd need new
Not only env hackery -- we don't have a good way to put libraries from Nixpkgs into users' |
|
We have literally been [accused of being part of the Stasi](#35292 (comment))
Nope, that literally was a question (like "why are you even pushing this?"), not a statement.
Secondly, note that that whole conversation wasn't addressed to anyone involved here.
Let me cite a piece of #35355 (comment)
> So, I follow at GitHub issues and look into `git log -p --grep pulseaudio` (seriously, just look at the log) and see this constant push for PulseAudio by
> default. I ask myself "Why is that?" I see three possibilities: I simply don't understand something, incompetence, malice. So I ask technical questions like
> "why do you even need it? and why do you need to link against libpulseaudio in apps that support ALSA when they would work via ALSA->PA adapter anyway?`. And
> get no answers. Instead I get ignored and PRs get merged. So I make a PR that goes the other direction (#35041), and get 👎s that cite same factually
> incorrect technical arguments.
>
> Note that in the recently merged #35005 and ignored #35041 I'm exactly concerned that people will use arguments of #35292 for PulseAudio by default.
>
> Then, just as #35005 gets merged, I see #35292 pop up after the long discussion of #29250 (and by the same author as #29250!) using exactly the arguments I was
> concerned about. I though I were dreaming, but I were not.
The last sentence is still a food for thought for me.
and have had some PulseAudio-related PRs compared to the [systematic extermination of Jewish people](#35292 (comment)).
Well, yes. Because
> That poem is about social responsibility. Not connecting PA to the net in a social responsibility to our users.
and if some of you are still like "well, I don't really care about the issue", then, yes, that poem is exactly about the issue.
I specifically tried not to mention all of this in this PR because this has purely technical merits. But whatever.
@grahamc, note that in #35355 (comment) you accuse me of accusing some people here, but if you look at the order of messages in the original thread, you'll notice that my message wasn't even addressed to them. (The part about the statistics indeed was, and that I addressed in my reply.) Just sayin'
Please go reread #35355 (comment). You are free to disagree with my motivation, but you can't claim I'm simply an anti-PA cultist (but I am an anti-PA cultist), hence this whole issue should be dismissed.
|
|
To be clear, I'm a strong -1 on this change and similar attempts to _**change our currently PulseAudio-supportive policy**_ without an explicit move by the
community to accept this as a goal.
You see, my whole problem with this is I don't see a place where this "PulseAudio-supportive policy" was enacted. As I said in #35355 (comment) all I see is a stream of changes to `master` that make it harder and harder to decide on any other policy. If you point me to the discussion/vote that enacted this policy I'll back off from this issue and will stop poking all PRs that mention PulseAudio.
@fpletz
Have you explored a solution like mesa-drivers in `/run/opengl-drivers`? The problem with that approach is that NixOS will be needed for PA-based applications. Maybe the RUNPATH can be patched so they will fall back to `libcardiacarrest`?
Please, elaborate. I'm unsure how `/run/opengl-drivers` is supposed to work on non-NixOS systems. AFAIK, we just shove those paths everywhere we can.
@abbradar
Does it try to start it by itself if not started when using `libpulseaudio`?
Oops, sorry, I misread that part as being a question about `libpulseaudio`, not about the application. But the rest is still valid.
libglvnd
As I noted in #35374, in my opinion, `libglvnd` was made for completely different reason: to support different `libGL`s for different screens. It's good that Nixpkgs has it now, but it doesn't solve `LD_LIBRARY_PATH`/FHS problem. I can make "`libpulsevnd`" with just `sed`, as it's is purely mechanical since there's no state except "PA lib loaded or not", but, in my opinion, it makes no sense, because it doesn't solve the underlying problem.
I'm ok if we solve that problem first (or make `libpulsevnd`) before merging this. I don't want to inconvenience anyone (unlike #35355 did, just sayin'), if you think FHS problem is too much of inconvenience, ok, I see your point.
My intention with `libcardiacarrest` was to make other policies other than "PulseAudio by default" possible, easy and convenient. If Nixpkgs needs some more changes to make it even smoother, ideally, so smooth that it would stop being a political decision altogether (because either choice would be equally convenient), ok, I'm all ears.
So, in short, I see I'm lacking `support32Bit` in this PR (will do) and Nixpkgs lacks some sane solution to `LD_LIBRARY_PATH` problem (I made several proposals in #31263, I will experiment with those). Anything else?
|
Just to be clear -- when application uses
I agree that it was made for a different reason, what I meant is that our current usage of
FHS was just an example of problems with
May be the solution yes -- I'm not sure if that much work is worth it but technically that should solve what I pointed out. I hope there's something better though -- personally I feel it's too much complexity. Before implementing anything serious however we'd need to find out if it's a behavior change in the end and if it is, should we do it or not. |
|
@grahamc Hm, I see your point -- my understanding was only correct given that PulseAudio isn't started by apps when it's not available and this isn't the case as @oxij pointed out so it's a change of behavior.
Well, actually, it's not. On current `master` we link against `libpulseaudio-vanilla` which is `libOnly` version of PulseAudio. That is, our `libpulse` can't start PA daemon unless you have it in PATH already (because it provides no daemon itself), and you're unlikely to have it in PATH unless you enabled the daemon in NixOS.
So, in this regard this PR changes almost nothing. (Sure, somebody could have explicitly put PA daemon into their PATH and started to implicitly to depend on that `libpulse` behavior to start PA daemon, but I think it's only proper to remind them that they are doing it wrong.)
|
|
Ah, you have answered my first question simultaneously with my post ^^. |
|
Just to be clear -- when application uses `libpulse` (or > `libpulse-simple`) and tries to open a connection to it with some default settings, would those libraries try to launch PulseAudio?
I just answered most of that in my previous comment. To repeat, `libpulseaudio-vanilla` does it best to start PA daemon, but unless you had it in PATH already or you had the service already, it fails. This PR doesn't change much in that regard (because of the `libsOnly` thing on `master`), but if you did have PA in PATH, but didn't notice it, this PR does harden your config.
I agree, that on current NixOS `libpulseaudio-vanilla` under common config this PR doesn't do much hardening under normal circumstances (it has other benefits, though). My problem is that PA is so complex it's too easy to screw it up. I mean, Firefox, of all the proponents of PA, fail to use the library correctly (https://bugzilla.mozilla.org/show_bug.cgi?id=1444519). What do you expect from mere mortals?
> libglvnd
> libpulsevnd
Ok.
|
|
@oxij Please cut it out with the constant attacks on and belittling of other contributors. (E.g. asking them if they're Stasi. We're talking about a sound system here, FFS.) The tone of smug superiority is also getting a bit tiresome. BTW I have no strong feelings about PA, to be honest ALSA worked well enough for me for years. But it makes sense to standardize on one sound system, just as we standardize on a C library, init system, kernel, etc. That doesn't have to be PA necessarily, but my relatively uninformed impression is that PA is currently the most widely supported by applications. |
|
@edolstra technically speaking, if NixOS isn't going to select a One True WM, the approach offered doesn't change the status of PulseAudio API that applications support, it can just be routed through an actual daemon or via |
|
@7c6f434c It changes the status on non-NixOS systems, though, since they won't have the real pulseaudio in |
|
I consider all of the pros rather philosophical than pragmatic, let me argue:
Relative size to the closure size of any running system I'd start elsewhere if closure size was to be improved. 2MB is marginally small.
That code had
In that README I see lots of accusations, but no solid proofs about the software as unethical or unpatched.
We try to package software so it doesn't crash, while I see benefit in crashing software as a QA, that's not the desired outcome of our work as Linux distribution. |
|
@edolstra Please read the very last sentence of this post first. Because I feel like you never read all of anything I write. Sorry, if I misunderstood.
@oxij Please cut it out with the constant attacks on and belittling of other contributors. (E.g. asking them if they're Stasi. We're talking about a sound system here, FFS.)
That was exactly my intention as specified in
> I specifically tried not to mention all of this in this PR because this has purely technical merits.
The tone of smug superiority is also getting a bit tiresome.
Well, my writing is fairly representative of the way I normally talk (a lot and passionately about the topics I care about), so I guess I'm such a [censored for smug superiority reasons] jerk then. Okay.
Please note, however, that I'm much less smug and/or overly-passionate when people actually address my technical arguments. The main source of my tone of smug superiority comes from the fact that when I f*ck up, I acknowledge it, fix it, and move on (which is easy to confirm by reading my messages to this issue tracker), while most of what I consider technical f*ckups in Nixpkgs persist even when you're just one revert (or one merge) away from fixing it. Which I do constantly point out, yes.
If you would just address the technical arguments and clearly document all trade-offs Nixpkgs is supposed to make, I would shut up.
For instance, this whole PA thing looks like "we want the most vanilla firefox to run on Nixpkgs, even if it produces some security issues" trade-off to me. It is a valid convenience-to-security trade-off (I don't like it, but it is valid). Is it documented anywhere? I don't think so.
impression is that PA is currently the most widely supported by applications
To recap #29250
> $ cd nixpkgs/pkgs
> $ ag alsaLib | cut -d ':' -f1 | sort | uniq > alsa
> $ ag libpulse | cut -d ':' -f1 | sort | uniq > pulse
> $ cat alsa pulse | sort | uniq -d > both
> $ wc -l alsa pulse both
> 272 alsa
> 139 pulse
> 87 both
>
> So, ~185 expressions mentioning ALSA without libpulse, ~52 expressions
> mentioning libpulse without ALSA. I think we have a clear winner in
> "better supported by applications" category.
I don't care which one is the default if one can use Nixpkgs without having a single bit of PA on the system. Before `libcardiacarrest` that was hard, now it's easy.
If most NixOS users want to make PA the only supported sound system on NixOS, then, please, go ahead. Same with "NixOS is systemd-only distro" and other such issues where NixOS disagrees with SLNOS some of which you mention.
All I really want from you (@edolstra and the rest of the core team) is an official document that outlines those decisions, trade-offs and arguments for them so that people could argue by using counterarguments and not by making smug comments about the current state of `master` you unilaterally bestow upon us.
|
|
Relative size to the closure size of any running system I'd start elsewhere if closure size was to be improved. 2MB is marginally small.
```shell
$ du -csh $(nix-store -qR /nix/store/censored-libpulseaudio-11.1)
1.7M /nix/store/censored-fftw-single-3.3.7
76K /nix/store/censored-speexdsp-1.2rc3
36K /nix/store/censored-libogg-1.3.3
556K /nix/store/censored-flac-1.3.2
1.0M /nix/store/censored-libvorbis-1.3.5
528K /nix/store/censored-libsndfile-1.0.28
120K /nix/store/censored-libICE-1.0.9
40K /nix/store/censored-libSM-1.2.2
36K /nix/store/censored-libXau-1.0.8
32K /nix/store/censored-libXdmcp-1.1.2
1.4M /nix/store/censored-libxcb-1.12
3.1M /nix/store/censored-libX11-1.6.5
428K /nix/store/censored-dbus-1.10.24-lib
2.0M /nix/store/censored-libpulseaudio-11.1
```
That's without `/nix/store/censored-systemd-237-lib` and its deps (and without the GNU bloat).
That code had `"--disable-pulseaudio-shared"` - I wouldn't consider this an accident. The code instructed to do so.
I don't understand you argument here. Please, elaborate.
In that README I see lots of accusations, but no solid proofs about the software as unethical or unpatched.
That README links to an accompanying `src/pulse.c` which is full of smug comments about those accusations. Did you read that one?
> Since it's a different implementation, it makes some buggy software crash sometimes. Which is good.
We try to package software so it doesn't crash, while I see benefit in crashing software as a QA, that's not the desired outcome of our work as Linux distribution.
Right, hence the next list item in the OP and "Request For Testing" in the topic.
|
|
@edolstra In all honesty, I imagine that the current (before this PR) state of `libpulse` on non-NixOS is pretty flaky anyway. I mean, you have to coordinate major PA versions for it to work, and they do change pretty frequently (twice a year or so).
@ all
But assuming we want to fix all of this, I've been thinking about it, and I have a question and a possible solution to any answer to that question. Can please someone walk me how you imagine `libGL` and `libpulse` (vnd or not) on non-NixOS _should_ work?
Let's say a user runs Debian and installed some SDL2 game and some system tool via nix.
Where `libGL` and `libpulse` should come from for the game?
- Debian's `/usr/lib`?
- ~/.nix-profile?
- Some other special place?
In what order? (If they are present in several of the aforementioned places.)
When user does `sudo thesystemtool` where those libraries should be loaded from now? (And should we even care about such a use case? I mean, special treatment for `sudo`. Eww.)
When `thesystemtool` is a setuid binary?
Now, to the solution.
I propose we implement `NIX_LD_LATE_RPATH` env var for ld-linux that is to be used for loading libs when all the other possible load paths are exhausted and which is ignored when ld runs in secure execution mode (setuid). This is similar to `NIX_LD_LIBRARY_PATH` of #31263, but
- it is not a security hole for setuid binaries,
- it can't be used for lib overrides,
- hence, it doesn't introduce another place to f*ck things up because you, as an app developer, get no real benefits by overriding it (as literally anything else wins over such an override).
What this solves:
- For Steam (the original motivation of #31263) you can create FHS chroot with /usr/lib with libGL and other stuff you need and set `NIX_LD_LATE_RPATH=/usr/lib` and it should, probably, work (I'm not sure about how Steam works in detail.)
- For this issue+FHS you can do the same.
- For this issue+non-NixOS users you can wrap all files in `~/.nix-profile/bin` with `NIX_LD_LATE_RPATH=/nix/store/somewhere-special-where-libgl-and-libpulseaudio-live exec .this-bin-wrapped "$@"` or just set `NIX_LD_LATE_RPATH` in `~/.bash_profile` or something.
Pros:
- Not a security hole.
- Steam games would probably work.
- FHS chroots look and feel more like real FHS chroots.
- This can be merged.
Cons:
- Somewhat ugly.
Does this sound ok? Patching ld-linux seems to be easy enough.
|
|
Unless I'm missing something, that would also fix #9415 and remove the need for https://github.com/guibou/nixGL. |
|
Sound servers are better for applications than directly consuming APIs of the underlying platform. It allows much more flexibility in sound output. I think we should embrace PulseAudio, allow Jack for professional real-time sound I/O, and deprecate direct use of ALSA. Additionally, with an audio server, say PulseAudio, it is feasible to write a client in a scripting language and use it without any native code or even platform dependency (PulseAudio also runs on macOS, FreeBSD, OpenBSD, and Windows). This is a step in the right direction towards truly portable interactive applications. OpenBSD also ships a sound server turned on by default, called |
|
@yegortimoshenko Sound daemons and "directly consuming APIs of the underlying platform" are completely separate issues. The first is a process, the second is an API. In your own example, you won't be able to implement PA client in pure Python or LISP because PA is very far from being anything like 9P (of Plan9) or OSS, you'd need at least some FFI library for it (because just look at the actual PA API). And, I argue, OpenBSD ships with |
|
|
You are right in that |
|
NixOS/nix#1080 + something like tbd files on darwin means we can build against library interfaces not libraries and then automatically reuse the intensional store path rewriter to link any dynamically-linked library implementation we want. Yes, that's a huge amount of work away, but might be the only non-political way to resolve these sorts of things. |
|
Wow, okay, I take that point back. I didn't think anyone would be crazy enough to actually parse and generate PA socket protocol messages (and I'm pretty sure their format is unstable, but small subset would probably work). https://github.com/mscdex/paclient/blob/master/lib/client.js gives me chills, but I agree that this is better than the code in the vanilla EDIT: The last sentence is a joke. |
What situations? You see, I find it strange that "the common user" supposedly wants pure DRI (Wayland, which is a library) instead of X11 (which is a daemon) and, at the same time, a sound daemon (be it PA, jack or sndiod) instead of some common library API. I agree that both sound daemons and X11 have their uses, but why would you want any of them on a normal laptop I have no idea. |
|
I actually like X11 (good parts, including being a server) and PulseAudio more than Wayland and ALSA, so it's consistent. I'm quite sure people like Wayland because it's new, not because it's not a server. Anyway, it is beyond the point: the actual problem here (I think) is that you want to replace In that case, why not just add |
Well, okay, then. Let's agree to disagree on that point.
I do own a build farm and I did rebuild most of Nixpkgs with this change without issues already. Most of the discussion above is politics. |
I understand that, but it results in the app using ALSA directly. What I mean is, your diff adds |
You can do that too (and in the README linked above I recommend doing exactly that for |
|
@Ericson2314 if I understand those issues correctly, they have a much more profound effect than my #36881 (comment). And I'm not sure how you plan to implement all of that on top of current nix and ld-linux. But it would be nice to be able to do something like that, indeed. |
|
@Ericson2314 Also, I think that if what you actually want is fast rebuilds (for security and stuff), you don't actually need most of that is discussed in that issue. Proper |
|
@oxij but with the things I mentioned, mass rebuilds either go away or can be speculatively done in complete parallel as long as symbols aren't mass-changed. Absent exported functions in headers, a compiler ABI change, or some refactor moving other output files around, that won't be the case! |
|
And that's 0 purity loss other than trusting the path renamer (which is only slightly more risky than the references detection we trust today). |
|
Path renamer might be more risky than reference detection: the reference detection needs to find at least one instance of all the copies of a string, path renamer needs to catch them all… |
|
Mmmm, good point @7c6f434c |
|
Given that:
I am going to close this PR. Let us not construe this as a statement either for or against the idea or code raised here. However, I do think that such a change should either not break anything in any case compared to the current situation (which, from my reading of the discussion, is not currently the case), or that it should go through an RFC. And given that @grahamc appears to be strongly against the change, maybe it should go through an RFC even if it does not break anything. The new RFC process should hopefully make it hard for a RFC to get lost, so the situation is not like before it with all RFCs falling into oblivion. |
What?
libcardiacarrest(https://github.com/oxij/libcardiacarrest) is a trivial implementation oflibpulse*PulseAudio library API that unconditionally (but gracefully) fails to connect to the PulseAudio daemon and does nothing else. See https://github.com/oxij/libcardiacarrest/blob/master/README.org for more info.With this we switch to linking against
libcardiacarrestinstead of the vanillalibpulseaudioby default. NixOS then overrides this with the vanillalibpulseaudioviaLD_LIBRARY_PATHwhen user enables the daemon service.Motivation
Pros:
libcardiacarrestby accident, unlike the vanillalibpulseaudio(SDL did this before, see tree-wide: fix pulseaudio references; fix SDL expressions #36377).libpulseaudiois no longer an ethical and security liability (see https://github.com/oxij/libcardiacarrest/blob/master/README.org for the case againstlibpulseaudio).Cons:
libpulseaudioon app-by-app basis for a temporary workaround is pretty trivial.LD_LIBRARY_PATHinstead of appending into it will need fixing when running with PulseAudio daemon. Or we can do something like glibc: add NIX_LD_LIBRARY_PATH #31263 (but, hopefully, a bit better). Or you can just override the broken app with the vanillalibpulseaudioand forget about it.Related things
This is a better version of what I wanted to have with #35374 which did the same with
libpressureaudio. The problem with linking againstlibpressureaudioby default is that many apps just start usingapulseemulation of PA API and completely ignore native ALSA. This hurts performance, ignores cool things you can do with yourasound.conf, and puts pressure onapulseto emulate more of the PA API, which could eventually turnapulseinto a monsterlibpulseaudioalready is.libcardiacarrestis tiny (even by comparison toapulse, not just tolibpulseaudio), all it does is it reports to the caller that PulseAudio daemon is unavailable, all the apps I tested then just switch to other output plugins like ALSA or JACK. This closes #35374.What I did
What I want you to do
Merge plan
After somebody else can confirm that running with PulseAudio daemon works, I think, in principle, you can merge this immediately because I'm pretty sure it doesn't break anything sufficiently common and overriding with the vanilla
libpulseaudioon app-by-app basis for uncommon things (while things get fixed, or just forever) is trivial.You could keep it here for a week or two anyway so that people could test it, but the practice shows that people don't test Nixpkgs PRs until they get into
master, so, inevitably, there are going to be surprises. I'd like this to get intomasterASAP to be over the surprises ASAP.Hydra job would be nice, though.
So. Study this branch. Study the source of
libcardiacarrest. Confirm I'm not doing anything stupid or evil. Try this with PulseAudio daemon. Merge.