nixos/pipewire: add transparent ALSA/PulseAudio/JACK support #93725
Conversation
ofborg
bot
added
6.topic: nixos
|
I just added both JACK and PulseAudio transparent emulation support. This allows running dependent programs using PipeWire as a backend instead. I also decided to set the ALSA support to false by default which not only is consistent with these new options but also makes it fully backwards compatible now. |
nglen
changed the title
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
If I use |
|
can you give more info for how to test this? i was not able to get any kind of audio output with any of |
|
Similar thing to me. Devices are off. Having pipewire log: |
Thanks for noticing. I accidentally made a modification in refactoring which broke this without noticing. For files, |
I tested with the following among others:
I will say that the PulseAudio library in particular still has some unimplemented functions and weird oddities but this is on the PipeWire side. Be careful with |
|
Having |
|
I just realized where the problem is. I was using a slightly older version of nixpkgs than this pull request. Updating to this version breaks the daemon on my side. Reverting #93672 appears to fix the issues though I'm not sure why. |
|
Just found the issue in upstream Since I can't reference GitLab, the commit is this. I know this is the issue because manually symlinking the directory from |
|
confirmed paplay and pavucontrol appear to work after reverting pipewire to 0.3.6, but i wasn't able to make qjackctl or cadence work, they couldn't find the jack server. didn't try with alsa. will try 0.3.9 which seems to have at least changed that line... |
|
tried to build 0.3.9 but it gives this: bisected it down to PipeWire/pipewire@154f981 which is the same commit that changed |
|
I just checked the paths, it looks like we should just need to move |
|
On second thought, we might have to move the entirety of |
|
can we just change it to reference |
|
I'm not sure either, but if it works it works. |
|
so here are all the things i've gotten working on my setup with
cadence still appears broken. can you test on your end? |
|
It's broken on my end as well. |
ofborg
bot
added
10.rebuild-linux: 11-100
and removed
10.rebuild-linux: 1
10.rebuild-linux: 1-10
labels
|
@jchv Thanks for noticing that. I accidentally used a string instead of a list, both are valid values but only lists merge. The commit I just pushed should fix it. |
|
Thanks, that worked like a charm. Now onto the next problem... the wrappers still don't work. I can't help but feel the problem for me must be PEBCAK. From within my GNOME/Wayland session: ...oddly, I checked to make sure I wasn't doing anything weird, but nothing that's currently active in my configuration twiddles with edit: Still not really sure. Looks like it is getting set in pam-env as expected. Things mysteriously drop off as they nest. $ grep -q LD_LIBRARY_PATH /proc/1/environ && echo match # systemd
$ grep -q LD_LIBRARY_PATH /proc/3001/environ && echo match # udisksd
$ grep -q LD_LIBRARY_PATH /proc/2791/environ && echo match # gnome-keyring-daemon
match
$ grep -q LD_LIBRARY_PATH /proc/2781/environ && echo match # systemd --user
match
$ grep -q LD_LIBRARY_PATH /proc/5950/environ && echo match # gvfsd-metadata
match
$ grep -q LD_LIBRARY_PATH /proc/5566/environ && echo match # vscodeSo for VSCode, it looks like it drops at gvfsd-metadata, which has the Meanwhile... $ grep -q LD_LIBRARY_PATH /proc/2781/environ && echo match # systemd --user
match
$ grep -q LD_LIBRARY_PATH /proc/2851/environ && echo match # systemd --userSo it seems it gets lost in gnome-shell. I am pretty convinced my problem with the wrappers must somehow be on my end. If I jump into a VT, the environment variables are all there as expected. Something is clobbering The volume controls inside gdm after boot are also broken, so I don't think it has to do with my per-user GNOME settings, unless it is expected that the pipewire wrappers won't (currently) activate over there. edit 2: OK. I think I found the problem: #90201 - and with that, I can conclude it really doesn't have anything to do with this PR. However, I suspect it will be a problem for a reasonable subset of users. Though I am ordinarily running SwayWM, I would guess GNOME + Wayland is a pretty standard configuration, and as it is this is fairly broken right now. |
|
One last note. I tried applying the patch in #90201 (comment) and now everything works largely as expected. So for future readers, if you want to use this on GNOME 3 + Wayland, you will probably need to patch this for now. It would be nice if there could be a generalized workaround that just finds a way to pipe With all that being said, this is not too related to this PR specifically although I have a feeling it will have an impact on it for sure. |
@jansol thanks! I tried pipewire 0.3.12 with 59cbf97 and vlc's volume is still super quiet. EDIT: issue filed at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/307 EDIT 2: the issue is fixed in master |
|
Sooo.... wait for next week's (presumably) 0.3.14 and then merge unless there are big regressions? Having the nixos module merged would make further testing easier anyway... |
|
I would only like to see this merged after us from @NixOS/gnome approve on this. The service is default enabled in GNOME and we maintain it. (will should change the maintainers to |
|
As far as I can tell this will not work in GNOME+Wayland at all, because of #90201. Am I missing something? edit: To be clear I still eagerly await this PR to be merged, I just also suspect it may be unwise to make it a default in GNOME until that problem can be worked around. |
Yeah, I believe GNOME is only at the phase of "try this feature out" and not "let's use this now". |
|
how can we make this work with fhsenv applications like steam and lutris? steam games work fine with |
There was a problem hiding this comment.
Only few edges to polish but I do not foresee any compatibility issues with GNOME, as long as the shims are off by default. GNOME team can work on fixing the conflict with disabled-by-default rt-scheduling (#90201) later.
I also checked the changelogs up to 0.3.13 and we will want to update for the crash fixes but other than that, I did not see anything interesting. Well, 0.3.11 introduced rudimentary hsphfpd (packaging status tracked in #87910) but according to pali’s comments in pipewire/pipewire!295 it is not ready to be enabled by default yet.
| jack-libs = pkgs.runCommand "jack-libs" {} '' | ||
| mkdir -p "$out/lib" | ||
| ln -s "${pkgs.pipewire.jack}/lib" "$out/lib/pipewire" | ||
| ''; | ||
| pulse-libs = pkgs.runCommand "pulse-libs" {} '' | ||
| mkdir -p "$out/lib" | ||
| ln -s "${pkgs.pipewire.pulse}/lib" "$out/lib/pipewire" | ||
| ''; |
There was a problem hiding this comment.
Why not just have the meson flags include /pipewire and use the outputs directly?
There was a problem hiding this comment.
There are two reasons I didn't do that. One is that I don't like the package output should depend on module internals. That seems like a potential backwards compatibility issue in the future. We probably want to change the module eventually to avoid using LD_LIBRARY_PATH once a way is setup (and the inevitable mass recompilation acceptable). The second is that currently the output can be used as an override on FHS and wrapper style packages, the exact ones that tend to cause problems with this setup. For example the following works:
pkgs.tor-browser-bundle-bin.override { libpulseaudio = pkgs.pipewire.pulse; }This is, of course, only valid when development information like headers aren't required.
| spa_plugindir = join_paths(pipewire_libdir, spa_name) | ||
|
|
||
| -alsadatadir = join_paths(pipewire_datadir, 'alsa-card-profile', 'mixer') | ||
| +alsadatadir = join_paths(pipewire_libdir, '..', 'share', 'alsa-card-profile', 'mixer') |
There was a problem hiding this comment.
Should not this go to alsa output?
There was a problem hiding this comment.
This directory is actually used by the SPA plugin and not the compatibility layer. The reason it was moved to pipewire_libdir is that there is a direct dependency link to which was causing cyclic dependencies. It might make more since to move it to $lib/lib/spa-0.2/alsa/mixer to make it more obvious.
The compatibility layer directories are $lib/lib/alsa-lib and $out/share/alsa. These could be moved to a separate output but are quite small and wouldn't remove the dependency on alsaLib due to the previously mentioned SPA plugin. I am open to this if it is preferred though.
There was a problem hiding this comment.
I guess this is fine for now, thanks for the explanation.
|
FWIW I've been using this and noticed that switching from pulseaudio to pipewire with nixos-rebuild switch doesn't work at all. |
|
@L-as You need to log-in again as you cannot modify the environment of running session. |
This replaces the temporary RPATH fix with the new upstream patch from jtojnar. It also removes the reference to the dev output.
ofborg
bot
added
10.rebuild-darwin: 1-10
and removed
10.rebuild-darwin: 0
|
Why not update directly to 0.3.13? Otherwise looks good to me. |
|
Sorry, that was a mistake on my part. Just updated. |
|
Verified that screen recording works in GNOME Shell and Thanks. |
|
Thanks everybody! 🎉 |
Janik-Haag
added
the
12. first-time contribution
Motivation for this change
This allows ALSA programs to interact through PipeWire.
The options are the same as in the JACK module for consistency. I enabled it by default since that is what JACK does and it seems less confusing for end users however this technically makes it backwards incompatible. If you prefer it off by default I can do that instead.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)