Pulseaudio by default, if sound is enabled #35292
Conversation
nixos/modules/config/pulseaudio.nix
Outdated
| @@ -87,7 +87,8 @@ in { | |||
| hardware.pulseaudio = { | |||
| enable = mkOption { | |||
| type = types.bool; | |||
| default = false; | |||
| default = config.sound.enable; | |||
There was a problem hiding this comment.
It's IMHO better to set hardware.pulseaudio.enable in the config attribute of this module with lib.mkDefault. Otherwise the manual will be regenerated if the user sets sound.enable to false.
There was a problem hiding this comment.
OK, sure. I will need to do some more testing once my computer is done with some bigger rebuilds.
|
While we're at the sound topic: I wonder if it's better to disable sound by default but enable it in the template configuration.nix from |
|
I would prefer an interface like:
|
|
With regards to @fpletz's disabling sound by default, would using the |
|
@samueldr Definitely, but will everyone read the release notes? 😄 |
|
@fpletz well:
|
|
stateVersion should be fine |
|
I know it is not, but sincerely I hope this is a joke or just trolling of the OSS community.
first they came for pulseaudio by default in firefox
then they came for pulseaudio by default in the whole os
then they proposed to disable sound by default if you don't use pulseaudio
**DIDN'T I TELL YOU EXACTLY THIS WOULD HAPPEN?**
Now, @Mic92, @lheckemann, @gebner and @7c6f434c, do you see the point behind arguing about #29250, #35005 and #35041?
In short: strongly against this.
Before proceeding, can, please, someone from the PA camp address the following question I've been putting around these threads for a while now (this exact form is from #35041)
Apps that can use both ALSA and pulseaudio generally don't need libpulseaudio even when you run pulseaudio daemon. They'll happily play sound through ALSA and pulseaudio daemon will happily take its audio from ALSA.
hardware.pulseaudio disabled? You get sound via ALSA.
hardware.pulseaudio enabled? You get sound via ALSA -> pulseaudio adapter.
Why do we need to build anything with libpulseaudio again? (Except some apps by crazy people which should be resolved on case-by-case basis.)
As for the crazy apps we now have `libpressureaudio` which you can link against to give PA-API to the crazy people in 5% of the code of PA, and without any daemons.
PulseAudio should not exist. Full stop.
|
@fpletz We should enable sound if |
|
Seriously, are you serious? Do displayless systems with speakers not exists in your universe?
|
I'm talking about a sensible default. If you run a headless system with sound output you can easily enable it. |
|
How is either of
- no sound by default,
- running pulseaudio by default - a daemon that provides no useful services to 99.999999% of the users,
sensible?
Can please someone explain to me why do want to shove one of the ugliest pieces of code I ever seen down everyones' throats?
Lets say you are in that 0.00000001% of the users that need pulseaudio. Why do you want make everyone else to disable it?
Seriously, I see no other explanation behind this flush of PRs pushing pulseaudio down our throats except for trolling or malice (just search the nixpkgs issues, I spend so much time debating this issue that I start to wonder if it's all a conspiracy to prevent me from doing any useful work).
Are you from the Stasi? Does it have a zero day you want everyone to have? Seriously, what is the point?
You want software mixing? It works with ALSA. You want per-application volume? It works with ALSA. You want bluetooth? It works with ALSA. You want output switching? It works with ALSA. You want firefox? It works with ALSA. You want firefox with WebRTC? It works perfectly with ALSA via `apulse`/`libpressureaudio`. The only thing PulseAudio does ALSA currently doesn't is _dynamic_ output switching, and, surprise-surprise, PulseAudio sucks at doing that too (compared, for example, to jackd, which can not only sound switch with _zero_ latency and _no_ hiccups, but it can also do dynamic MIDI stream switching at the same time).
I see no sensible reason to have `hardware.sound.pulseaudio` at all, let alone to enable it by default.
But assuming there are non-malicious people that actually want it, what I think is a sensible way to proceed with pulseaudio (again, except for just removing it) is to treat it as we treat `libOpenGL`: we should link against `libpressureaudio` by default (like we link against `mesa` by default) and allow overriding it with the Poettering's `libpulseaudio` at runtime with `LD_LIBRARY_PATH`.
That would be sensible. You wouldn't link against this security nightmare, nor would you run it by default, nor would you drag all its deps by default, but if you do need it for some reason I can't imagine, `hardware.sound.pulseaudio` would be able to set your `LD_LIBRARY_PATH` for you.
This PR is not sensible. Sorry to inform you, but this PR gone from a stupid idea discussed at least four times before straight to the realm of mental-institution-level-of-crazy with "lets have no sound by default". I see a point of not enabling X11 by default: it's another daemon you have to run, not everyone need it. What is the point of disabling ALSA by default? Under Linux its free. You don't have to do _anything_ to have sound under Linux. You want to actually disable sound by default? Disable ALSA in the kernel config by default. That would actually increase security be default (but will make almost everyone to compile their own kernel).
So, maybe no actual sound by default is a bit to much, right? But you do still want PulseAudio by default, right? I have another wonderful idea for you!
I propose we run `screen` instead of `getty` on bare ttys by default. All modern applications require a ttys and you can only have so many virtual ttys provided by the kernel, so we should run a daemon to do proper tty software mixing by default. `screen` is the de-facto standard for that, all other distros have it, all terminal emulators support it, so lets wrap all our ttys into screen by default and solve all the pesky `TERM` and `termcap` issues for free at the same time. People like software mixing by default, right? Don't worry, if you have a display, not just a serial line, connected to your computer and want to run X11 on it, of course, you could still easily disable all of that.
|
|
Could we please stop with this religious and condescending discussion style and agree that we have users that want ALSA xor Pulseaudio and try to reach a consensus that works for everyone? Regarding disabling sound by default: I only brought it up because servers, VMs and containers generally don't need to have sound support. The sound module would add It is my impression that right now we build most software with pulseaudio if it is supported. So why is that the case? For instance, I do actually have problems with the ALSA pulseaudio plugin if I'm streaming to remote pulseaudio servers over the network. You might say now that pulseaudio is of course broken but that is not helpful for me because the network streaming part of pulseaudio generally works really well for my use case. Treating libpulseaudio like libGL sounds like interesting idea to explore. Does anyone know the libpulseaudio API well enough to know if we would run into trouble here? Does pressureaudio mock/implement the complete libpulseaudio API and are the ABIs compatible? Does anyone know if the libpulseaudio API exposes functionality that is needed and can't be implemented or emulated via the ALSA plugin? The reality is that most NixOS desktop users counting by the votes in all the PRs and issues that are linked here are using Pulseaudio. As a compromise, why not go a similar route here as with the proposed solution to |
BTW Chrome/Chromium works fine without PA |
|
Franz Pletz <notifications@github.com> writes:
Could we please stop with this religious and condescending discussion style and agree that we have users that want ALSA xor Pulseaudio and try to reach a consensus that works for everyone?
If PA camp will properly answer to the raised counterarguments I'm ok with discussing this in a mild no-rage style.
My biggest problem with the PA camp is that it ignores technical arguments and goes straight to
The reality is that most NixOS desktop users counting by the votes in all the PRs and issues that are linked here are using Pulseaudio.
or similar. The minimal understanding of statistics shows that this is not a valid argument (systems without problems, like ALSA, simply produce no issues).
Same goes for Firefox data on builds with and without PulseAudio (submission of telemetry and PulseAudio builtin are not independent variables).
Take those misunderstandings of statistics (I think they are deliberate, hence "lies") and this constant pushing for PulseAudio to gain positive feedback loop that screws the statistics even more with "it's the default" effect (and to get free zero days on most Linux PCs). What does it tell me?
You already know what it tells me.
Regarding disabling sound by default: I only brought it up because servers, VMs and containers generally don't need to have sound support. The sound module would add `alsaUtils` to the system closure and an `alsa-store` service which is not needed at all.
Put this way it does sound reasonable, but `alsaUtils` and `alsa-store` are not really "sound support".
Sometimes I, too, wish to disable `alsa-store` and make sound volumes deterministic (like always set them to 50% on boot).
But since NixOS currently has no way do switch flags to `false` without breaking configurations I'm strongly against any of this.
It is my impression that right now we build most software with pulseaudio if it is supported. So why is that the case?
I have no idea (well, I have an idea, but you won't like my idea). SLNOS builds nothing with pulseaudio support and we are perfectly fine.
For instance, I do actually have problems with the ALSA pulseaudio plugin if I'm streaming to remote pulseaudio servers over the network. You might say now that pulseaudio is of course broken but that is not helpful for me because the network streaming part of pulseaudio generally works really well for my use case.
Good for you. The one time I needed such a thing I made it with ALSA loopback sound device and `arecord | ssh -- aplay` in three minutes.
Gives proper authentication too. Just sayin'.
Treating libpulseaudio like libGL sounds like interesting idea to explore. Does anyone know the libpulseaudio API well enough to know if we would run into trouble here? Does pressureaudio mock/implement the complete libpulseaudio API and are the ABIs compatible?
Does anyone know if the libpulseaudio API exposes functionality that is needed and can't be implemented or emulated via the ALSA plugin?
Nobody knows `libpulseaudio` API well enough, not even the authors. It's enormous.
But, `apulse`/`libpressureaudio` seems to work with everything I tested (firefox, some other apps that have ALSA by default like mpv and cmus) and I heard it works with other common abusers of the Linux ecosystem like skype.
As a compromise, why not go a similar route here as with the proposed solution to `sound.enable` by keeping the current `hardware.pulseaudio.enable` default (false) and add a line to the configuration.nix by `nixos-generate-config` to make new users more aware of what options are available?
I am going to be okay with that if we implement libGL treatment first and then write something like this to the `configuration.nix`:
```nix
# Enable PulseAudio daemon and point libpulse to libpulseaudio.
#
# hardware.pulseaudio.enable = true;
#
# Note that you don't need to enable this to get either of
#
# - sound playback,
# - software sound mixing.
#
# It will out-of-the-box with ALSA.
#
# Also note that NixOS links against libpressureaudio instead of
# libpulseaudio by default. libpressureaudio implements libpulseaudio
# API over pure ALSA. This means all your `firefox`es and `skype`s will,
# too, work out-of-the-box without enabling the above daemon.
#
# Finally, note that libpressureaudio implements libpulseaudio API in 5%
# of the code of original PulseAudio (via `apulse`). This means that
# running PulseAudio daemon is a 20x security liability. Enable at your
# own risk.
#
# Use cases where you might want to enable PulseAudio daemon:
#
# - you want per-application volume and apps you use don't support it
# with ALSA (most do, try it, grep their man for "softvol" if they try
# to control Master/PCM volume by default), you don't want to manually
# add per-application `softvol` sinks into your `asound.conf` for ALSA
# apps that don't support softvol out-of-the-box and you don't want to
# run jackd instead (works much better than PA, recommended if you
# need a sound daemon).
# - you want sound over network and don't want to run jackd and touch
# you `asound.conf`,
# - you want sound over Bluetooth and don't want to run jackd and touch
# you `asound.conf`,
# - you need to have dynamic stream switching and don't want to run
# jackd.
# Remove all PulseAudio support from your system by default (will cause
# a mass-rebuild). Use this if you are paranoid.
#
# nixpkgs.config.pulseaudio = false;
#
# You can still run apps that require PulseAudio by wrapping them with
# `apulse` like `$ apulse app args`
#
# environment.systemPackages = [ pkgs.apulse ];
```
Btw, jackd, too, has two versions: jack1 and jack2, and jack2 is not the better one, it's just different. nixpkgs defaults to jack2, which I locally override to jack1 (because I like it better, it does all the same things I need, but doesn't require dbus). But their libs have the same API (unlike revisions of PA), so we could do the same libGL thing for jack too.
|
|
I will create a separate pull request to disable sound by default if stateVersion >= 18.03 |
|
I will create a separate pull request to disable sound by default if stateVersion >= 18.03
But since NixOS currently has no way do switch flags to `false` without breaking configurations I'm strongly against any of this.
I'm sure I won't be alone in this. Just sayin'.
`stateVersion` is a hack nobody uses. Just sayin'.
|
|
Well, given existence of opposition and lack of opinion from Eelco Dolstra, Rob Vermaas or Domen Kozar, if it were an RFC it would stall forever. Unfortunately, it is not an RFC and so it might actually proceed. |
People don't use stateVersion, the NixOS module system uses stateVersion. |
|
@grahamc I don't follow, but let's put that discussion in the upcoming separate PR. |
|
That is fine, it wasn't for you -- but for oxij's assertion that nobody uses stateVersion. |
|
Let's please take all discussion about disabling sound by default to #35355 |
|
As we're informing new users about the options with the merge of #35355, I think we can close this for now. Thanks to everyone for their input. |
|
The |
|
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.
Also, let me say my thanks to all the people who showed behind-the-scenes support in this discussion. Its not like I made cardiacarrest just for you, or anything. (Seriously, I would've made cardiacarrest even I all of you were Poettering worshippers here. My rage is just to stronk.) But if all of you just intruded here instead of sending me emails of "I support your arguments, but don't want to go near that discussion" things would've been much easier. I think.
|
|
@oxij I wonder how many of the people you mention still use mainline NixOS, though. I mean, PulseAudio is strictly less intrusive than systemd. |
|
I mean, PulseAudio is strictly less intrusive than systemd.
Except most people run PulseAudio directly connected to the network, for systemd this is not the case^W^W^W^W joking, of course it is (see their timesync, dns and http logging), but those, I think, still are separate parts you can disable. That's out of scope of this discussion, though.
|
Motivation for this change
Major applications like Firefox no longer support a bare-alsa setup, the justification being that only a very small percentage of Linux users does not use pulseaudio.
This pull request still allows people who really want to to disable pulseaudio, but makes it the default on systems with sound enabled. I think it will make it easier for people to get started with NixOS if their sound works out of the box.
Minimal headless systems will also be unaffected, because they should already have sound disabled.
Previous discussion in #29250, which was closed by me due to lack of consensus, but at the time, Firefox did not yet require PulseAudio.
EDIT: I misunderstood a bit, Firefox will still apparently run with Alsa, but it's not maintained and if there's bugs with the Alsa support, there's no guarantee anybody will fix it. The thing that triggered nixpkgs to build Firefox with Pulseaudio is that some playback quality is clipped in some scenarios.
Things done
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)