Your patch basically says "to have sound you should use pulseaudio by default". This is incorrect. Firstly, nixpkgs uses `nixpkgs.config.pulseaudio` option in most places to decide whenever pulseaudio should be used by default. The correct way to implement your desired behavior is to set `nixpkgs.config.pulseaudio = true;` when `hardware.pulseaudio` is enabled. Current implementation just forces everyone to run another Poettering invention by default. No, thank you. Secondly, you don't even need to run PulseAudio to have PulseAudio-only programs (f*ck those, btw) work as witnessed by https://github.com/i-rinat/apulse

Well, PulseAudio is at least better at coexistence than systemd… It is clear that Firefox is going to drop any support for ALSA real soon now, so I wrote a few scripts to make sure PulseAudio is launched when Firefox is, and I was relieved that normal ALSA-using software like MPlayer doesn't suffer. (I do not run mainline NixOS purely because systemd breaks parts of my desired workflow)

The problem is that PulseAudio — like all software by this author — is a moving target with unpredictable API changes. For example, to make apulse work wiht Firefox you need to implement some more random libpulseaudio functions (we do have apulse in NixPkgs, but it is not enough to run Firefox default build, and I haven't found any fork of apulse that would be large enough).

What? Source? They did drop it to being off by default with much drama, but this would be just too crazy. ALSA's API is stable, there should be zero maintenance for that part of XUL. Anyway, if they do I'm sure TorBrowser guys would revert that change and we can just plunder their patch.

Ironic. PulseAudio breaks parts of my desired workflow too (kinda-pro-audio setup), should I stop running NixOS too? (Btw, what do you run?)

Also, it doesn't work too well with other pro-audio software, adds perceptible latency and stutter.

Which is why Mozilla has resources to maintain PulseAudio module, but has no resources to maintain ALSA module? Hmm... I propose a better solution: just disable PulseAudio by default for everything and wrap Skype and other PA-only stuff with `apulse` by default. Suddenly, everything magically works by default.

This is just extrapolation from the past track record. It is not that rare that they break compatibility in some parts of the browser, and if they go far enough to break by default, they usually break it in a way that is hard to reverse after some more time.

I think they have a plan to do some rewrite that changes intra-XUL APIs; at least that seemed to be the most coherent available explanation why would they switch off ALSA by default in the first place.

Well, I have personal interest that enough people use NixPkgs, as for _mainline_ NixOS I am sure you (SLNOS) will diverge with it at some point…

I just take NixPkgs, use NixOS config/runner script export for the services that are anonying to set up manually (X.org, CUPS…), and write the bootscripts by hand. In the current iteration this happens to include a non-trivial amount of Common Lisp, but the busybox version worked mostly fine, too. When boot time is dominated by mounting all the filesystems from a HDD, writing bootscripts is just too easy… Speaking of what to use — I agree with your point in the FF PR about running browsers in separate UIDs; I would actually prefer running different browser windows in separate UIDs, but some changes in Gecko break SlimerJS, I am not sure if there are more breaking changes to come, and a new Firefox instance with a fresh profile takes some time to start. Is there any better way to do lightweight Gecko than what SlimerJS does (using WebKit and Blink seems to be a contribution to the establishment of «IE 6.0» 2.0, which I would prefer to avoid)? Or maybe I just miss a way to build a Firefox instance with heavy-at-start-up features removed.

Erm, does running something through PulseAudio add stutter to normal software that bypasses PulseAudio? (I cannot exclude that, but my experience is not that bad).

Here I honestly don't understand your surprise: using random stuff from a large API can make it easier to throw together a somewhat working audio subsystem.

No magic — `apulse` is abandoned, so there are many PA API functions to add to it…

Maybe that would work, but would you call this "works well with jack"? Jack and ALSA play ok together with ALSA plugins. I can run jackd and ALSA clients will just forward their io to jackd. But how am I to reconfigure everything to switch from PA to jack when I want low-latency sound? I kinda don't want to loose system notifications and stuff (what if I were blind and used espeak for navigation?). While I can imagine some crazy NixOS hackery that could make it kinda work, I fail to see how that would be better than just going all-ALSA by default.

Not broken yet. Can be reverted or apulse can be patched when and if they break it.

They say it works for Skype: https://bbs.archlinux.org/viewtopic.php?id=187258 Firefox still has ALSA. Everything else I know of uses ALSA. I see no blockers here.

Yes, it happens. It depends on hardware, apparently. My main concern is latency, though.

I still bear some naive hope that we will be able to merge most of SLNOS into nixos. Surely, we have some radical patches that would probably never get merged upstream (like ungoogling, just grep nixos for "8.8.8.8", there is some serious Google-propaganda there), so we don't even PR them. But most stuff, naively, should be ok. And when we assemble enough of cool rejected stuff in one place people won't be able to ignore it, because they will want it. That's the master plan. AHAHAHAHA! ahem.

Heh, nice. Can I see those scripts anywhere? I feel like there could be something useful for SLNOS in them.

Well, not yet.

Hm, maybe a global PA would break things for me too (in my case most software just doesn't try to use PA, but Firefox uses it; but PA is user-local and even allegedely system DBus instance is not global — I am OK with PA and DBus as long as their instances live in small isolated worlds and don't take over everything). I wouldn't know because I don't run literal NixOS on things where I play sound, though.

My plan is just to make it even simpler to reuse NixOS parts and, ideally, to have multiple Nix-based systems installed side-by-side with common bootloader management. I am not completely excited by the module system, so I want just to pluck random pieces from random branches, picking a couple of configs from SLNOS will probably come some day, too.

This is the main script to start following the references from: https://github.com/7c6f434c/7c6f434c-configurations/blob/master/init-less-system/my/pseudo-system-thinkpad-rebuild.sh The Common Lisp version is bootloader-management-compatible with that, and in too much flux right now. The starting point is described in the last lightining talk in: http://european-lisp-symposium.org/static/2017/lt2.pdf

Ah, right, NixOS runs system-wide PulseAudio by default, I only hope that gets declared unsafe at some point. I still expect that other UID's PulseAudio shouldn't be that bad for latency.

I would put it under systemd.packages = [ cfg.package ]; line (and say `= true`) for simplicity. Also maybe do `sound.enable = true` somewhere there too.

gnidorah <notifications@github.com> writes:

True. But if you suddenly change it to `false` in nixos people will loose binary caches for those packages, since hydra doesn't care about `nixpkgs.config`. I'm all for changing it to `false` by default, but it needs to be a separate change to nixpkgs that changes all those `or true` to `or false` or something like that. On the other hand, if user runs pulseaudio service I see no argument against setting that option to `true` in the service config. In the worst case user will get an evaluation error saying they already declared that option to be something else. Which is good.