Change:
I get errors like: This shared object is provided by derivation, not i.e:
Just some additional info: using the wrapper script provided by doesn't solve it either.
I would like to hear from someone more experienced, but maybe an aggregate package (like for texLive) could solve this.
You are right. I was talking about the PulseAudio plugin simply because I believe that it is the only plugin used by almost everyone. Other plugins are kind of “special”, or “professional” and can be dealt with on per-expression basis, but the PulseAudio plugin should work out of the box without any extra configuration from the user or the expression maintainer.
BTW I just found this topic from 2009 with a relevant discussion: An aggregate package seems to be a viable solution. The problem with this (which seems to be the one concerning in the ML) is that adding plugins won’t be possible without rebuilds.
It's really tricky because ALSAPLUGINDIRS is a compiletime constant in alsa-lib. (so the env-var approach won't work) I tried to add a dir for plugins like for the graphics drivers to /run/alsa-plugins. The problem with this is that alsa-lib builds smixer into ALSAPLUGINDIRS so it has to be inside the derivation. You can pass the configure flag --disable-mixer an then alsa-lib will build, but then gstreamer won't build anymore (i guess it tries to link against the smixer in alsa-lib). I haven't tried the aggregate package yet because I'm not sure how to make everything use the aggregate derivation instead of the alsa-lib.
By the way, looks like should be removed. Looks like there used to be a in Nixpkgs that made respect this environment variable, but now it is .
Shouldn’t the commit that removed the “unused” variable be reverted? I mean, we need a beautiful solution, but at least it worked before that.
All the plugin so-files are relatively small in comparison to libasound (<300 kB together vs. ~1.4 MB), so we might consider having the default attribute contain the plugins needed for pulseaudio playback. Our attribute no longer needs to build, so we should be able to reverse the dependency and make depend on . /cc should know more about pulseaudio packaging. Perhaps it's a similar situation in there.
I was thinking about integrating the alsaPlugins into the alsaLib derivation altogether. (I need the jack plugin as well) It may not be an elegant solution but it's not that big an overhead (maybe some dependencies will need adjustments) And build all the plugins that are buildable. Also I think the workaround was removed in official alsa project. See Dynamic Loader helpers section here:
I'm using this workaround right now:
Also see , which maybe adds more complexity to this issue because of a 32-bit library / 64-bit plugin mismatch.
(triage) status?
I think I'm seeing an effect of this in attempting to update the Factorio derivation, but master nixpkgs has a more up to date version of alsaLib, but it appears to be trying to load the plugins from the system installed version of alsaPlugins.
I also got hit by this issue while trying to run Nix-installed Audacity 2.2.2 (from nixpkgs master) on Ubuntu 14.04. Audacity playback doesn't make any sound because, it seems, hardcodes its plugin search directory.
I worked around this by creating a directory containing a symbolic link to and adding that directory to .
I've found a workaround in Guix manual alsaPlugins the following lines to ~/.asoundrc or
Wow. Thanks for the tip gnidorah <:
Still relevant in 19.09 :/ Does anyone know the syntax for importing rate conversion plugins ("speexrate", "samplerate", etc.) directly inside "", or if there's a method without hackery by now? Btw, seems to be affected by this, I'm using your workaround from here right now, together with .
Meanwhile it is even ALSAPLUGINDIR instead of ALSAPLUGINDIRS (notice the missing plural 'S')
we could patch like so. But beware, this is actually only for the the second time that i am patching c code. I tried it with and the converter and it's working so far. <details<summaryenvironment-plugin-</summary</details
Or we could just bring back the original patch.
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. One nice effect is that we don't have to patch alsa-libs any more. Thoughts on how to best take advantage of the new feature?
Without writing an updated patch for multiple plugin directory support, the upstream's can probably be put to use immediately by pointing to symlink farm of plugins. Haven't tried this, but I suspect it (or something similar) would do the trick. The linked GUIX thread included review of a patch for multiple plugin directory support. It looked promising but its growing stale with outstanding feedback. They've not responded to news of upstream ; I do wonder if they'd consider contributing their multi-directory patch or not - especially given that there's now some kind of upstream support.
Guix's property will automatically create a create a symlink union of the relevant plugins for single-entry search paths. It's how Chromium extensions and plugins are discovered, for example. It's just because we haven't gotten around to update alsa-lib yet, as it missed the latest 'staging' cycle.
Hi, I'm the author of that patch from Guix, although it grew out my reading of the old unused nixpkgs patch. I ran out of energy for keeping track of all the "C issues" one has to think about... if alsa-lib's new ALSAPLUGINDIR meets our needs then I'll be glad to leave the patch behind. Feel free to use the patch in any way you like — it does work fine and, as a part of Guix, the license is GPL3+. Or, as a part of alsa-lib, maybe it's LGPL2.1+? Anyways, feel free...
I marked this as stale due to inactivity. &rarr;
I implemented the aggregate package approach () and appreciate your thoughts on it.

Discussion:
<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>