-
-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos/pulseaudio: remove broken support for 32bit on 64bit systems #157352
nixos/pulseaudio: remove broken support for 32bit on 64bit systems #157352
Conversation
Back in 2014, the following commits patched alsa-lib to support running apps with 32bit sound on 64bit platforms, and configured /etc/asound.conf to leverage that support: ab8ef63 0c8ad65 A recent commit updated alsa-lib (1.2.5.1 -> 1.2.6.1), and removed the patch, but left the pulseaudio module unchanged, meaning it continued to generate an etc/asound.conf containing the `libs` field, which alsa-lib cannot recognize (the patch was providing support for that field). aeea1bb As a result, a system whose configuration enables pulseaudio can no longer run alsa utils, regardless of whether support32Bit is enabled. E.g. $ alsactl monitor default alsa-lib control.c:1464:(snd_ctl_open_conf) Unknown field libs Cannot open ctl default $ speaker-test -t wav -c 2 speaker-test 1.2.6 Playback device is default Stream parameters are 48000Hz, S16_LE, 2 channels WAV file(s) ALSA lib pcm.c:2576:(snd_pcm_open_conf) Unknown field libs Playback open error: -22,Invalid argument Once the issue was identified, it was reasoned that the 32bit support is too niche a use-case to justify patching a system as complex as alsa, especially in 2022 and with pipewire providing a viable alternative solution. Remove the unused (and now unusable) 32bit configuration code from /etc/asound.conf, so alsa-lib can again parse it and run properly.
As described in the previous commit, this option was removed. Remove references to it, and produce etc/asound.conf files that alsa-lib is able to parse.
@L-as You mentioned,
I'm not sure what action the notes should suggest to affected users. Could you advise? |
I also have this issue in current master (not pulseaudio but pipewire/alsa.enable = true) with this patch, I check speaker-test alsamixer and some steam games(Hollow Knight and Oxygen Not included) and works fine |
... Now I'm confused about what |
Can someone try this with a 32-bit game?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The alsa 32bit options have been pretty widely recommended in the past due to steam so I'd like to see a proper deprecation error instead of just silently removing the options.
The pipewire portion of the diff looks good to me otherwise.
Use an assertion to display a proper error message if the user's config has the `support32Bit` option enabled. Example error output: error: Failed assertions: - `hardware.pulseaudio.support32Bit` is no longer supported.
@@ -210,6 +218,11 @@ in { | |||
} | |||
|
|||
(mkIf cfg.enable { | |||
assertions = [{ | |||
assertion = !cfg.support32Bit; | |||
message = "`hardware.pulseaudio.support32Bit` is no longer supported."; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The alsa 32bit options have been pretty widely recommended in the past due to steam so I'd like to see a proper deprecation error instead of just silently removing the options.
@jansol That makes sense. This commit adds a clearer message, but did you mean an actual deprecation process, where we fix the currently broken 32bit support and provide a deprecation warning about its eventual removal? That would require reintroducing the patch that was removed in #154276, but I'm not opposed to doing that if it's warranted (and it sounds like it is).
I'd also like to provide a more informative message than I've done in this commit, something like,
In order to support 32bit audio on a 64bit system, please use ??? instead.
But I don't know enough about this domain to do so. Is there a pipewire-related suggestion that would be appropriate in place of ???
above?
cc @L-as
02c141e
to
404138f
Compare
Tested this branch on my system and it fixed pipewire support for ALSA within Mixxx. |
Thanks for working on this! Small note: this also drops (similarly broken) 32bit alsa support for jack and pipewire (removing the |
@dtzWill That's a good point, but I'm considering changing the direction of this PR to fix the 32bit support (re-adding the alsa-lib patch that was removed) and deprecate the option rather than removing it right away. (see #157352 (comment)) I'll update the PR title one way or the other though 👍 |
Given that it's not clear what alternative to suggest to users who currently rely on the 32bit support, I think the best thing is to fix what's currently broken, and leave the deprecation/removal of 32bit support to someone knowledgeable enough to compose appropriate deprecation warnings (including suggested config changes for affected users). So I've created an alternative PR that confines itself to fixing what's currently broken: #157631 |
Closing this in favor of #157631 |
Motivation for this change
In #154276, alsa-lib was updated and old patches removed. One of those patches, from 2014, allowed alsa-lib to recognize a
libs
field in /etc/asound.conf, and the pulseaudio module leveraged this to optionally add support for running both 32bit and 64bit apps on 64bit platforms.With the patch removed, alsa-lib is unable to parse the /etc/asound.conf generated by the pulseaudio module (regardless whether the user has opted into 32bit support), and alsa utils such as
alsactl
,alsamixer
,speaker-test
, are broken. E.g.Once the issue was identified, it was reasoned that the 32bit support is too niche a use-case to justify patching a system as complex as alsa, especially given the availability of pipewire.
I removed the
support32Bit
option from pulseaudio and changed the generated config to use syntax recognized by alsa-lib. I then removed several references to this option from other modules (steam, jack, pipewire).Note: I rebuilt my system against this branch and confirmed that alsa works as expected for my use-cases. I have not tested steam, jack, or pipewire.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes