Code change:
<ins> { lib , pkgs , alsa-lib , plugins ? [ pkgs.alsa-plugins ] , lndir , symlinkJoin , runCommand }: let merged = symlinkJoin { name = "alsa-plugins-merged"; paths = plugins; }; in runCommand "${alsa-lib.pname}-${alsa-lib.version}" { meta = with lib; { description = "wrapper to ease access to ALSA plugins"; platforms = platforms.linux; maintainers = with maintainers; [ gm6k ]; }; outputs = alsa-lib.outputs; } ( ( lib.concatMapStringsSep "n" ( output: '' mkdir ${builtins.placeholder output} ${lndir}/bin/lndir ${lib.attrByPath [output] null alsa-lib}  ${builtins.placeholder output} '' ) alsa-lib.outputs ) + '' cp -r ${merged}/lib/alsa-lib $out/lib ( echo $out | wc -c echo ${alsa-lib} | wc -c ) | xargs echo | grep -q "^(.*) 1$" || ( echo cannot binary patch exit 1 ) rm $out/lib/libasound.la rm $out/lib/libasound.so.?.?.? rm $dev/lib/pkgconfig/alsa.pc rm $dev/nix-support/propagated-build-inputs cp ${alsa-lib}/lib/libasound.la $out/lib cp ${alsa-lib}/lib/libasound.so.?.?.? $out/lib cp ${alsa-lib.dev}/lib/pkgconfig/alsa.pc $dev/lib/pkgconfig cp ${alsa-lib.dev}/nix-support/propagated-build-inputs $dev/nix-support sed -i  $out/lib/libasound.la  $out/lib/libasound.so.?.?.?  $dev/lib/pkgconfig/alsa.pc  $dev/nix-support/propagated-build-inputs  -e "s@${alsa-lib}@$out@g" '' ) </ins>

Related discussion:
text: i guess it is still here (somehow :)) but it is doing nothing for loading rate converters since they are neither loaded through patched from nor through from but through from But yes, now that i reread your comment, that way of telling alsa where to find libs is gone.
Since I opened this issue I'm not sure what to do with it, but since learning more about alsa config this is no longer an issue for me. I'll post my config hoping it helps people: I have in my And my config looks like this: This finds the jack plugin just fine due to the If I want to run something (for example steam) that won't be able to run with jack then I just fallback to my mixing PCM with stopping jack exporting
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
This still needs to be addressed (either by the wrapper or by patching the package, maybe both). I've been using the same trick as and it works well enough, but it'd have been great to have the package itself or the wrapper handle users' additional plugin paths out of the box.
With the release of v1.2.4 on 19 Oct, alsa-lib gained official support for an runtime environment variable. It was in , following with some Guix folks. Note that this environment variable only supports a single directory, unlike the (effectively unused?) alsa-plugin-conf- which provided a plural environment variable.