pulseaudio: enable by default in NixOS if sound is enabled #29250
Conversation
|
Feedback from IRC: Should this really be enabled by default on headless servers? I think that's a valid concern, perhaps it should only be enabled if X11 is enabled? |
|
Definitely don't want it on my headless servers. I use the |
|
Definitely don't want this laggy piece of shit at all on any of my
systems.
This was discussed multiple times and rejected. Just search the issues.
TL;DR You don't want PulseAudio by default too.
ALSA requires _NO SETUP_ on systems with one sound card.
Placing
~~~~
defaults.pcm.card "name"
defaults.ctl.card "name"
~~~~
(see `aplay -l` for names) into /etc/asound.conf solves it for the rest
99%.
If your sound card needs special setup default ALSA configs don't
provide PulseAudio will need you to configure it too since it, surprise,
will play audio _USING ALSA_.
See `/nix/store/*-alsa-lib-*/share/alsa` if you want more features (like
device remapping, rate resample and any other stuff you will never ever
actually use for more than a day) or just want to know how it works and
what it can do (fun fact: ALSA has a LISP interpreter inside, you can do
almost anything you want with it).
The only legit thing you can't make it do with any config or LISP code
is dynamic input/output switching without application restart. That's a
library API limit. But this is only useful for pro audio setup you
perform on. And you want to use JACK for that, not PulseAudio,
PulseAudio will eat your frames.
Also, ALSA doesn't listen on any network interfaces (which is a good
thing). This is the only use case for PulseAudio I know of: sound over
network. You can use JACK for that too, but sound other network will lag
anyway, so PulseAudio is probably ok for that.
|
|
Strange I cannot remember having configured something with pulseaudio except enabling it - Am I just lucky for the last 5 years?
The network feature of pulseaudio is really cool btw - and it is not enabled by default. We have a Raspberry attached to the sound system and to play music on it, you just can use any pulseaudio application like that: Is it documented in our manual how to enable pulseaudio? I think this is what we should at least do. |
|
Unfortunately, whatever we do with Firefox build configuration, Pulseaudio is closer and closer to being required for sound support there. As I am running Firefox inside a separate UID, I run user-level Pulseaudio just for that user. (No opinion on NixOS setting beyond options being available, as I am not using that part of NixOS services in any case). |
|
Jörg Thalheim <notifications@github.com> writes:
Strange I cannot remember having configured something with pulseaudio except enabling it - Am I just lucky for the last 5 years?
Which means your ALSA is working perfectly without any config.
Congratulations.
Some ignorant question of mine since I did not use ALSA for a while:
- Most laptops have at least 2 "soundcards" these days for HDMI and analog is switching between both easily possible?
Yes. ALSA will expose both to all applications. If you want to switch
between them without using application options ("ALSA output option
somewhere") you can do that with ALSA_PCM_CARD environment variable,
e.g.:
$ ALSA_PCM_CARD=PCH /bin/my-program
See
$ cat /nix/store/*-alsa-lib-1.1.4.1/share/alsa/pcm/default.conf
for how this implemented:
~~~~
#
# Default output
#
pcm.!default {
@Args [ CARD ]
@args.CARD {
type string
default {
@func getenv
vars [
ALSA_PCM_CARD
ALSA_CARD
]
default {
@func refer
name defaults.pcm.card
}
}
}
type empty
slave.pcm {
# use card-specific definition if exists
@func refer
name {
@func concat
strings [
"cards."
{
@func card_driver
card $CARD
}
".pcm.default:CARD=" $CARD
]
}
default {
# use plughw as default
type plug
slave.pcm {
type hw
card $CARD
}
hint.device 0
}
}
hint {
description "Default Audio Device"
device_output {
@func refer
name defaults.pcm.dmix.device
}
device_input {
@func refer
name defaults.pcm.dsnoop.device
}
}
}
~~~~
As I said, the only thing it can not do is switch on the fly. You have
to restart the application with another env (or use in-application
switcher, if it has one).
Once upon a time I looked at that code and decided I want to make
another bit of asound.conf hackery to do the same for pcms, not cards (I
have 3 sound cards and some very specific pcm setup). My asound.conf:
~~~~
# Internal Intel PCH, headphones
pcm.internal "cards.pcm.default:CARD=PCH"
ctl.internal ctl.sysdefault
# External recorder
pcm.external {
type asym
playback.pcm {
type plug
slave.pcm "dmix:CARD=name"
}
# no dsnoop for security reasons
capture.pcm {
type plug
slave.pcm {
type hw
card "name"
}
}
}
ctl.external {
type hw
card "name"
}
# External USB audio card, speakers
# "notify" because I mostly play notification sounds using it
pcm.notify "cards.pcm.default:CARD=USB"
ctl.notify ctl.sysdefault
# Normal operation: play with internal, capture with external card
pcm.normal {
type asym
playback.pcm "internal"
capture.pcm "external"
}
ctl.normal ctl.internal
# ENV hackery so that one could do
# ALSA_DEFAULT_PCM=notify /bin/some-program
# and have everything in that process subtree to play though notify pcm
pcm.!default {
@func refer
name { @func concat
strings [ "pcm."
{ @func getenv
vars [ ALSA_DEFAULT_PCM ]
default "normal"
}
]
}
}
ctl.!default {
@func refer
name { @func concat
strings [ "ctl."
{ @func getenv
vars [ ALSA_DEFAULT_CTL
ALSA_DEFAULT_PCM
]
default "normal"
}
]
}
}
~~~~
- Can ALSA in the configuration we have on NixOS set the volume level per application?
Yes, you can create different pcms/plugs of "softvol" type. I don't use
it, though, I just configured volume using in-application softvol (mpv,
mplayer, cmus, almost anything has it already anyway) once and forgot.
- What about Bluetooth headset support for ALSA these days?
No idea. Last time I tried it 10 years ago it worked fine.
Michael Raskin <notifications@github.com> writes:
Unfortunately, whatever we do with Firefox build configuration, Pulseaudio is closer and closer to being required for sound support there. As I am running Firefox inside a separate UID, I run user-level Pulseaudio just for that user. (No opinion on NixOS setting beyond options being available, as I am not using that part of NixOS services in any case).
I hoped tor-browser people would fork that part too (because PulseAudio
is a security risk), but they seem to be very passive about it :(
My only hope now is `apulse`. I will run firefox using `apulse` for the
rest of history (or just switch to Pale Moon or something) if they
remove ALSA.
|
|
Some more info on ALSA softvol:
https://bbs.archlinux.org/viewtopic.php?id=131853
Apparently you don't even need that, ttable is enough.
|
|
Re: Firefox — I think ALSA sound output works fine (and might continue
to work for some time even without maintenance), but audio capture for
WebRTC via ALSA has already degraded from slightly fiddly to either
broken or really tricky to configure.
|
|
Pulseaudio also supports some other things that ALSA doesn't, like Bluetooth Audio support (not sure how well that works right now, been a while since I've had a Bluetooth headset), and I've generally had the impression that it's better supported by applications nowadays - like @7c6f434c alludes to. And dynamic source/sink switching is not an exotic feature at all. Besides, @oxij - this PR is only about changing the default, nothing would prevent you from disabling it. |
|
This latest change should disable it on headless machines that use minimal.nix, because for those, sound.enabled = false. |
|
Aristid Breitkreuz <notifications@github.com> writes:
Pulseaudio also supports some other things that ALSA doesn't, like
Bluetooth Audio support (not sure how well that works right now, been
a while since I've had a Bluetooth headset)
False. Bluez4 used ALSA directly, Bluez5 provides a generic interface
for sound streaming. PulseAudio uses it. ALSA has a plugin too
https://github.com/Arkq/bluez-alsa
and I've generally had the impression that it's better supported by
applications nowadays - like @7c6f434c alludes to.
It's true that there are some crazy people (like Skype developers and,
most recently, Mozilla) that really want you to run PulseAudio for some
reason. The problem is that they give no rational technical reasons for
it while there are serious reasons against it (see below).
Systemd, Dbus and Avahi have exactly the same problem. And are shoved
down your throat exactly the same way ("Pst! Hey! Hey! Boy, am I seeing
you using physlock (ntpd) with systemd? Didn't you know systemd has its
own screen locker (timesyncd) already? What? You don't like it? You
know, funny thing, utmp (ntp) is depricated now. You know, actually, its
so old and outdated we completely removed the support for it (we made
timesyncd impossible to disable). Does physlock (ntp) still work? No?
Perfect! Ehem. I mean, we are always working hard to improve the Linux
software ecosystem. Thank you for your support!")
I have no other explanation for this except there exists The Church of
Poettering (if you didn't know: he is the primary author of all of those
daemons) that holds secret meetings where they plan how to spoil all
usable OSS software in the most gruesome way possible and how to
infiltrate other OSS projects to help in that noble goal.
They also do a lot of preaching of false facts like "libpulse is easier
to use that alsaLib" (subjective, if you don't like the generality of
alsaLib API use libao instead) and "libpulse is more stable than
alsaLib" (provably false) and similar.
Now to the falseness.
$ 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.
Next, PulseAudio is demonstrably worse for applications.
* ALSA just works.
* PulseAudio plays audio using ALSA.
* Its provides a useless level of abstraction because 99.9% of things
PulseAudio does can be done via pure ALSA (as demonstrated by my
previous messages). And you probably don't even want the last 0.01%.
But if you do want it, PulseAudio is the worst thing you can use for
that.
Because:
* As with most Poettering inventions, it has shitty API and provides a
high attack surface.
* I don't want my system to be hijacked from a browser via
JavaScript Audio API. Thanks but no thanks.
* As most Poettering inventions, it's highly inefficient and eats CPU
cycles.
* Last time I looked at the source it introduced latency by ignoring
hardware audiobuffer size and copied frames around the most
inefficient way possible. (I heard they tried to fix that, but I
haven't checked since.) As a consequence, it dropped frames from
time to time.
* As most Poettering inventions, it only works well for orthodox system
setups. Anything Poettering doesn't use you shouldn't even think of
using.
* Last time I looked, it resampled everything. ALSA changes sampling rate
of the hardware when possible (in ALSA the sample rate of the first client
wins, which is not ideal, having priorities would be better, but
still, ALSA potentially butchers sounds of all but the first client,
while PulseAudio butchers everything). As a consequence, lossless
music is completely useless with PulseAudio (unless your FLACs are of
the sample rate Poettering uses).
And dynamic source/sink switching is not an exotic feature at all.
* Did you use it today? This week? Month? Year? Anytime? I mean, the
part ALSA can't do. Do you seriously need to constantly switch between
sinks in a program that doesn't support it natively, but there's just
no way you can restart it with a different env? What is your use case?
Anyway. I'm not claiming that. I'm only claiming that
* ALSA can do all the useful parts.
* PulseAudio implements that feature in the most horrible way possible.
Its unusable for anything except watching YouTube videos (YouTube
butchers the sound anyway).
* If you do use dynamic audio/MIDI source/sink switching and/or LADSPA
effect chains why, again, are you not using JACK which can do all of
that (can PulseAudio do midi? both ALSA and JACK can), actually works
as you would expect without dropping frames, introducing seconds of
latency (on long effect chains), resampling, and is better supported
by pro-audio software?
Besides, @oxij - this PR is only about changing the default, nothing
would prevent you from disabling it.
Yeah, right, let's promote the thing that's insecure, laggy, butchers
sound and makes multi-user systems with sound hard (and secure
multi-user systems with sound impossible) to _the default_, because The
Church of Poettering says so. Thanks, but no thanks.
|
Mic92
changed the title
|
I don't see why this should be default. I use NixOS on desktop and nothing requires me to enable Pulse Audio. |
|
What is going on? PR closed without comment, then branch deleted and re-created? |
|
@aristidb: I accidentally deleted many branches due to a typo and GitHub closed their associated PRs automatically. @grahamc was able to restore many of them but GitHub doesn't seem to have reopened this (or other?) PR(s). Furthermore, I don't even know which PRs were auto-closed, so I can't even reopen them until someone comments on it. Sorry for the trouble! |
This was the only one. |
|
@orivej nope, I've seen several, unfortunately |
|
@copumpkin You are right, I've received the notifications and did not pay attention. There were six more issues, but they are handled already. |
Because… people in general are not particularly good at being precise. What do you think of these “two” cases, @shlevy? Should similar ones be consistently happening, or would it be better to limit them with help of a machine? Also: https://botbot.me/freenode/nixos/search/?q=push+force 🙄 |
|
@michalrus PR backlog only grows with time. Less people with commit access → more load. Nobody would expect people under load to be more precise. As for help of a machine — well, nobody so far has managed to convince people to move to a VCS that actually cares about integrity. At least all the branches anyone cares about long-term are force-push protected, or so I hope (but I only care about I have no idea why people like to do PRs from branches inside |
Maybe because people (with few notable exceptions) don’t seem to care about integrity. Programmers. ¯\_(ツ)_/¯ Let’s maybe look at our, oh, oh, so to say, neighbors. Tell me, people of Nixpkgs:
|
|
Kernel development model is not scalable. It is not scalable down. (It is also what created git, which fits kernel development and only kernel development just because the things git cannot do sanely are infeasible at kernel scale anyway) |
Which things do you mean? =) Just curious. I’ve seen with my very own eyes, how properly configured Git can keep hordes of very junior developers from doing silly things—just like the ones that are consistently happening in Nixpkgs (cf. that IRC log). Oh, but you cannot change server side behavior (hooks) on the proprietary GitHub®™©, which is the real problem w/ keeping larger (à propos scaling down) projects under reasonable control here… People will make mistakes, it’s unavoidable. It seems to me like we could be better off, if those mistakes weren’t blindly accepted by our central repo of choice, nay? (ﾉ^_^)ﾉ |
|
Please talk about the git/github/other unrelated topics on IRC, the mailing list or anywhere else :) Back to the issue at hand. It seems like most people are in agreement that pulse audio as the default isn't a good idea, and that we need some documentation for enabling pulse audio. @aristidb are you interested in documenting this? |
With 4 people against and 4 for the default pulseaudio (counting comments and likes) this question is not decided; this shows only the lack of interest. Personally I'm for pulseaudio by default because (1) it obsoleted the need to configure sound by editing configuration files, which is particularly valuable for the users who don't know what pulseaudio or ALSA are; (and I was also quite happy when I could delete my
Do you mean a new section in the NixOS manual about the audio configuration? The option |
|
I was going off @Mic92 comment "Is it documented in our manual how to enable pulseaudio? I think this is what we should at least do." That's a good question if this is something we really want in the manual or not. Maybe it makes more sense for a more in-depth howto beyond just enabling it to go on the wiki, since it really isn't reference material. As for what the decision is here, if we're not at a consensus I guess we leave the issue open for debate until more people speak up one way or another. |
|
@disassembler I don't think there is consensus either way (the opponents are louder, but the number of votes is in favor of it), which is why I'm not merging this. But I'm also not interested in patching over the lack of sane defaults with documentation. I'll just close this particular pull request, but if somebody wants to take it up, feel free to. |
|
In my opinion, we should agree on what the guiding principles are. And assuming we agree that we should be giving the user the best possible experience with the least number of surprises, then anything that helps make things "Just Work" should be enabled. The one key feature we need from pulseaudio is mixing for which we will need a piece of software for all the hardware that doesn't support hardware mixing. At this point in time, pulseaudio is that software. Of course if something better comes along that solves that problem, we should probably use that. But not being able to play multiple streams is a no-go. |
AFAIK ALSA does software mixing by default (when necessary) and in our configuration. I should probably disable pulseaudio on my system and see how far it could go. The main usability issues I expect are that:
|
Are you sure about that? As I recall we need to set up a dmix device for that to happen and I cannot find any config that does that. The other points you make are very valid - assuming we want sound to just work, pulseaudio really is our only option at this point in time. |
@oxij has posted the config above (
|
|
Orivej Desh <notifications@github.com> writes:
(1) it obsoleted the need to configure sound by editing configuration
files, which is particularly valuable for the users who don't know
what pulseaudio or ALSA are;
I repeat. You don't need to know `.asoundrc` exists 99.9% of the time.
All proper GUI applications have their own ALSA device selectors for
playback and capture, and their own volume controls.
There's no need to edit `.asoundrc` unless
* you have two or more sound cards, the default one is incorrect and
apps you use don't have the device selector (even then, you can add a
kernel cmdline, or udev rule, env variable, and not `.asoundrc` line)
* you do device/channel remapping (see my comments above)
* or insert sound effects (think, echo) into your audio output.
(and I was also quite happy when I could delete my `.asoundrc` instead
of tweaking it for another application that did not play well with the
current configuration);
Most likely you could as well just deleted your `.asoundrc` and it would
have worked with ALSA.
One upon a time I had such a problem too, but then I deleted my
copy-pasted from the Net `.asoundrc` and it just worked. Magic! I then
RTFMed ALSA docs and default configs and noticed that that random people
from the Net simply suck at configuring ALSA, which is why their
`.asoundrc` copy-paste usually doesn't work as expected. I switched to
using modifications of the default ALSA configs (they have everything
you will ever need) for my sound experiments, and all problems simply
vanished.
It is true that you had to configure `.asoundrc` (also `xorg.conf`) to
add dmix and solfvol stuff 10 years ago. People mostly forgot about xorg
now thanks to xrandr, but those broken ALSA configuration file snippets
still travel thru the Net, people mindlessly copy-paste them into their
`.asoundrc`s (when all they need 99.9% of the time is one line which
fixes the default sound card), ALSA does exactly what those snippets
ask, and people blame ALSA for it.
(2) ditto for using the console to configure sound (`alsamixer`) and
Most desktop environments have their own ALSA mixers built-in. For a GUI
`alsamixer` see `aumix`.
launch graphical applications: "If you want to switch between two
sound cards without using application options you can do that with
`ALSA_PCM_CARD` environment variable" — this is a ridiculous and
terrible desktop experience.
See above, also see below.
I should probably disable pulseaudio on my system and see how far it could go. The main usability issues I expect are that:
- some applications will not be able to play or record audio (e.g. Skype)
Use `apulse`. Also, don't use Skype.
- it will not remember per-application volume levels between application restarts
- it will not have per-application volume controls at all
See the very top of this message. Use in-app volume control. Of course,
if the app sucks you can define a new softvol device in ALSA.
- it will not have an easy way to switch between internal and HDMI sound cards
... without application restart when the app doesn't support it.
I agree that there might be a use-case here if you really need to switch
_all_ applications from internal to HDMI at once. Yes, ALSA was not made
for this. Use jackd. It will do it without adding any latency (!, really
absolutely zero, because jackd authors know their shit), unlike
PulseAudio.
- it will not have an easy way to switch between internal and a USB
sound card, and it will not switch back to internal when the USB card
is disconnected
Either you could restart the app with the new device (e.g. you play
notifications or only some apps like LMMS over USB sound card) or its
the above use case and you should use jackd.
- I won't be able to play sound on multiple sound cards at once
without editing configuration files
Correct. Use jackd for that.
Personally, I prefer configuration files for this type of thing.
Configure once, use anytime. With GUI tools you have to click too much
to get the same old result every single time. Also, every sufficiently
powerful GUI configuration editor turns into a programming language. I
prefer to write programs in text editors, not to draw them with a mouse.
# Thoughts
Having said all of the above, I agree that ALSA is shitty, but not
because alsa-lib is shitty, but because userspace-to-kernel interface is
too complicated (I would've loved them to simply do OSS dsp's with
alsa-lib/jackd-lib on top for userspace mixing, but alas).
I also agree that it would've been nice to have very simple app-to-mixer
interface and to be able to manage all volumes both on the mixer and in
each app (they have to share control or else pro audio software that can
do programmatic volume control like LMMS will go moot), but alas.
IMHO, jackd (simple userspace code) on top of OSS3 (simple kernel API)
would've been pretty much ideal.
Putting PulseAudio (extremely complicated userspace code) on top ALSA
(complicated kernel API) doesn't help. Which is why I argue for not
making already bad situation worse.
Peter Hoeg <notifications@github.com> writes:
> AFAIK ALSA does software mixing by default (when necessary) and in our configuration.
Are you sure about that? As I recall we need to set up a dmix device for that to happen and I cannot find any config that does that.
Yes. You had to do that 10 years ago (see above). Today ALSA will
automagically setup dmix for cards that don't support hardware mixing
and softvol for cards that don't support hardware volume control. If it
does not for your card: its a bug and you should report it.
The other points you make are very valid - assuming we want sound to just work, pulseaudio really is our only option at this point in time.
Assuming you're ok with it eating your frames and adding 300ms of
latency. Which I am not.
The only viable alternative to all this is jackd over OSS or ALSA hws
(which are, essentially, the same thing, but with million times more
code). But its one daemon more. And while it won't add latency it will
eat CPU cycles. Which is why I can't watch 720p videos with sound with
jackd on by Pentium 4, but I can with ALSA (yes, you can watch 720p fine
of P4 with mplayer). With PulseAudio even system notification sounds
laggg. (Why P4, you ask? Because it's a good usability test. If it works
fine on Pentium 4 it will work awesome on anything modern larger than a
thumb-drive-sized PC. I wish Firefox developers would test their shit on
P4. Its completely unusable now, which is why PaleMoon, whose authors
can't even code properly, is the only choice for low-power 32-bit
devices ATM.)
|
Is it possible to trim down systemd to just init system (just pid 1 and nothing more)? I mean say goodbye to
|
|
This conversation has become a little unproductive. Why don't we move this to the mailing list and stick to the issue at hand. |
|
Is it possible to trim down systemd
To the best of my knowledge, it's not possible. You can only run some of
the more usable alternative daemons (like syslog) in parallel.
|
ghost
mentioned this pull request
|
A kind suckless soul have sent me the following link [1]. It seems to be
a fork of `apulse` that implements/stubs-out all of the pulseaudio API.
I didn't even try to add it to nixpkgs (because I refuse to use software
that requires pulseaudio) but seems worth mentioning here.
[1] http://git.r-36.net/pressureaudio/tree/README.md
|
Motivation for this change
I think PulseAudio should be enabled by default. This is because I think it is the better supported option nowadays, and because it is easier to set up than ALSA.
Things done
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)