I don't have a linux machine at hand to test, but the ci passes.
The last problem with the alsa update was that it was failing on aarch64. It looks like it's okay now.
This looks good to me.

@L-as This change has left me unable to run any alsa utils, apparently because alsa-plugin-conf-multilib.patch was removed. That also appears to be what caused the failure @Artturin described in #151357 (review) .

What's the right way to address this? cc @nathanielbaxter

Here are a few examples of the errors I'm getting:

$ alsactl monitor default
alsa-lib control.c:1464:(snd_ctl_open_conf) Unknown field libs
Cannot open ctl default

$ alsamixer
ALSA lib control.c:1464:(snd_ctl_open_conf) Unknown field libs
cannot open mixer: Invalid argument

$ 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

@ivanbrennan This works perfectly for me on aarch64-linux. I assume the problem is specifically with cross-compilation? Is it fixed if you add the patch back? In any case, I think trying to fix the issue upstream is preferable.

I'm not even sure what the patch does!

@ivanbrennan did you reboot?

@L-as I'm on x86_64. I don't know enough about ALSA to debug this, or to say whether it's something that should be fixed upstream. I suspect there will be a lot of other people in my same situation. The only solution I currently have is to rollback my system to an older generation.

@Artturin I did reboot, but it made no difference.

@L-as It looks like this is related to the /etc/asound.conf generated by the pulseaudio nixos module (my nixos configuration has hardware.pulseaudio.enable = true). Note the libs.native and libs.32Bit fields in this snippet from nixos/modules/config/pulseaudio.nix:

  alsaConf = writeText "asound.conf" (''
    pcm_type.pulse {
      libs.native = ${pkgs.alsa-plugins}/lib/alsa-lib/libasound_module_pcm_pulse.so ;
      ${lib.optionalString enable32BitAlsaPlugins
     "libs.32Bit = ${pkgs.pkgsi686Linux.alsa-plugins}/lib/alsa-lib/libasound_module_pcm_pulse.so ;"}
    }
    pcm.!default {
      type pulse
      hint.description "Default Audio Device (via PulseAudio)"
    }
    ctl_type.pulse {
      libs.native = ${pkgs.alsa-plugins}/lib/alsa-lib/libasound_module_ctl_pulse.so ;
      ${lib.optionalString enable32BitAlsaPlugins
     "libs.32Bit = ${pkgs.pkgsi686Linux.alsa-plugins}/lib/alsa-lib/libasound_module_ctl_pulse.so ;"}
    }
    ctl.!default {
      type pulse
    }
    ${alsaCfg.extraConfig}
  '');

ALSA doesn't recognize the libs field. The patch adds support for it. It looks like the this is done in order to allow 64bit systems to run apps that use 32bit sound. See: 0c8ad65

I don't know enough about it to say whether there's another way to provide such 32bit support. Submitting the patch upstream does seem reasonable. cc @nathanielbaxter

In the meantime, I'm testing a nixos-rebuild against a branch in which I've re-added the patch. It's been building for over 4 hours so far, but I'll post again here once it finishes and let you know whether it worked. I looked at the patch and the source code it's patching in a little more depth and I'm optimistic that it should still work. If so, I'll make a PR.

@L-as It looks like this is related to the /etc/asound.conf generated by the pulseaudio nixos module (my nixos configuration has hardware.pulseaudio.enable = true). Note the libs.native and libs.32Bit fields in this snippet from nixos/modules/config/pulseaudio.nix:

  alsaConf = writeText "asound.conf" (''
    pcm_type.pulse {
      libs.native = ${pkgs.alsa-plugins}/lib/alsa-lib/libasound_module_pcm_pulse.so ;
      ${lib.optionalString enable32BitAlsaPlugins
     "libs.32Bit = ${pkgs.pkgsi686Linux.alsa-plugins}/lib/alsa-lib/libasound_module_pcm_pulse.so ;"}
    }
    pcm.!default {
      type pulse
      hint.description "Default Audio Device (via PulseAudio)"
    }
    ctl_type.pulse {
      libs.native = ${pkgs.alsa-plugins}/lib/alsa-lib/libasound_module_ctl_pulse.so ;
      ${lib.optionalString enable32BitAlsaPlugins
     "libs.32Bit = ${pkgs.pkgsi686Linux.alsa-plugins}/lib/alsa-lib/libasound_module_ctl_pulse.so ;"}
    }
    ctl.!default {
      type pulse
    }
    ${alsaCfg.extraConfig}
  '');

ALSA doesn't recognize the libs field. The patch adds support for it. It looks like the this is done in order to allow 64bit systems to run apps that use 32bit sound. See: 0c8ad65

I don't know enough about it to say whether there's another way to provide such 32bit support. Submitting the patch upstream does seem reasonable. cc @nathanielbaxter

In the meantime, I'm testing a nixos-rebuild against a branch in which I've re-added the patch. It's been building for over 4 hours so far, but I'll post again here once it finishes and let you know whether it worked. I looked at the patch and the source code it's patching in a little more depth and I'm optimistic that it should still work. If so, I'll make a PR.

I feel like Nixpkgs is the wrong place for this patch. It's a complex piece of functionality added to alsa, when in reality, it doesn't even matter. We don't need to support 32-bit ALSA apps going through PulseAudio. It's a niche use case when you could just use Pipewire. I propose just fixing the PulseAudio module not to make use of that functionality.

We don't need to support 32-bit ALSA apps going through PulseAudio. It's a niche use case when you could just use Pipewire. I propose just fixing the PulseAudio module not to make use of that functionality.

@L-as That sounds like a reasonable stance to me if it's an unusual use-case. I don't know much about how audio works, is this a use-case that was more common in the past?

@ivanbrennan In the past 32-bit applications were much more common, and so were applications that directly interfaced with ALSA. This isn't true anymore, not to mention we have PipeWire now. I don't think it's a common use case anymore. The only scenario I can think of where this is still relevant is Steam with proprietary old 32-bit games that use ALSA directly, but you can just switch to PipeWire for that! Perhaps that's just something we should note in the release notes for the next NixOS release. What I don't understand is, why was this patch needed in the first place? Why do the other distros not need to do this?

@L-as Thanks for elaborating, I appreciate the context 👍.

Why do the other distros not need to do this?

That's a good question. I don't know, but given how old the patch is, I wonder if a different solution has since been implemented upstream? Some googling led me here, though I'm not sure what to make of it.

For what it's worth, I don't even have 32bit support enabled.

I propose just fixing the PulseAudio module not to make use of that functionality.

I'm still waiting on nixos-rebuild to finish, but once it's done, I can make a PR to remove the 32bit option from the PulseAudio module.