nixos/alsa: kill sound.enable and friends with fire

[K900]

Description of changes

This is an alternative take on #319839, which just removes most of sound.enable and provides instructions to mitigate the impact for people that actually use it for things.

Testing on JACK and Pulse setups would be very much appreciated. All the affected tests still work , except sfxr-qt which segfaults for seemingly unrelated reasons and pt2-clone which does not actually build (CC @fgaz for both of those).

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[fgaz]

pt2-clone: #326267

[fgaz]

nix build github:K900/nixpkgs/no-more-sound-enable#nixosTests.sfxr-qt succeeds on my machine

[K900]

Then it's just flaky I guess? Fun.

[Atemu]

Hm, now we'll have to find the two people who still use ALSA to review this...

[K900]

I'm more worried about the JACK and Pulse setups, really. Actually, @cillianderoiste @lovek323 can you please look over the changes to your modules?

[K900]

I'm just merging this before there's more merge conflicts.

[futile]

Thanks a lot! Probably also makes sense to post a heads-up to https://discourse.nixos.org/t/breaking-changes-announcement-for-unstable/17574?

[K900]

I would hope that the manual changes cover this.

[futile]

I would hope that the manual changes cover this.

I'll just post there then, and point people to the manual, if that's ok :) I always appreciate the heads-up from that thread.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/breaking-changes-announcement-for-unstable/17574/55

[slotThe]

@K900 Speaking as one of the two people still running ALSA, setting hardware.alsa.enablePersistence to true gives me an undefined variable 'alsa-utils' error upon evaluation—I suppose because this line was removed? Or am I doing something wrong?

(EDIT: I should note that the error does not go away if I add alsa-utils to my systemPackages)

[K900]

Yes, sorry. Please test #327290

[rnhmjoj]

I'm really not happy about this change: why did you have to completely remove the module? A simple rename to "hardware.alsa" would have been enough to clear any possible confusion. The migration instructions are basically "you can reimplement it in your own configuration". By this logic NixOS could just drop every niche module, afterall you can just do it yourself, no?

Also, you removed alsa-utils from the environment, which is another undocumented breaking change.

[K900]

We have to be at least somewhat realistic about what we support and what options we provide. This module goes back like 15 years, which was a very different time, and just renaming it would not make people remove it from their configurations (as they should, generally), or make the actkbd mess work with modern setups.

[rnhmjoj]

(as they should, generally)

Forget about the actkbd which has very limited use. Why should people be removing this module from their configuration?
If you use ALSA you would like to have a single toggle to install alsa-utils, setup the udev rules to restore the card settings and maybe even a toggle for the OSS compatibility (it's useful for BSD programs or old games).

[K900]

People should be removing this because all of this messes with Pulseaudio/Pipewire/JACK/whatever other sound daemon you're using (and you should be using one).

[rnhmjoj]

You can use ALSA without a sound demon and have the basic functionality of Pulseaudio/Pipewire/etc (per-application volume controls, software mixing, bluetooth audio...). Removing this module is really a pity because ALSA is basically the only sound system that can be extensively configured in a declarative way.

[K900]

Pipewire can absolutely be configured declaratively, including policy? I don't think Pulse can have declarative policy, but even that can have declarative configuration.