JACK applications can no longer connect to pipewire with JACK support

[sburris0]

Describe the bug

Sometime in the last ~2 months, JACK applications became unable to connect to pipewire. I have previously been using the reaper DAW with its JACK output + pipewire's JACK support, but this no longer works.

Steps To Reproduce

Steps to reproduce the behavior:

1. Set services.pipewire.jack.enable = true;
2. Install a JACK application (I tested reaper, qjackctl, and spectrojack)
3. Start the application
4. Observe the following errors in stdout:

   Cannot connect to server socket err = No such file or directory
   Cannot connect to server request channel
   jack server is not running or cannot be started
   JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
   JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
   error creating client

Repro notes

• Has occurred on both of my machines
• Someone else was unable to reproduce in a fresh VM

Expected behavior

I expect JACK applications to be able to connect to pipewire as they did previously.

Notify maintainers

@K900 @Kranzes

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 6.0.11, NixOS, 23.11 (Tapir), 23.11pre537656.7c9cc5a6e5d3`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.17.1`
 - channels(spencer): `""`
 - channels(root): `"nixos, nixos-hardware"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[K900]

Does this still happen if you use the pw-jack wrapper?

[sburris0]

[spencer@nixos:~]$ pw-jack
The program 'pw-jack' is not in your PATH. You can make it available in an
ephemeral shell by typing:
  nix-shell -p pipewire

[spencer@nixos:~]$ nix-shell -p pipewire

[nix-shell:~]$ pw-jack
The program 'pw-jack' is not in your PATH. You can make it available in an
ephemeral shell by typing:
  nix-shell -p pipewire

pw-jack seems to be missing

[K900]

Use nix-shell -p pipewire.jack.

[sburris0]

Yes, it does work as expected in that case

[nix-shell:~]$ pw-jack reaper
jack: created client
jack: non-realtime threads
jack: activated client
jack: deactivated client
jack: close client

[K900]

Are you maybe forcing LD_PRELOAD in your environment?

[sburris0]

I haven't used LD_PRELOAD anywhere and do not see it set in env vars

[K900]

Well the pipewire.jack.enable option should set it, so something must be unsetting it.

[alyssais]

I have this same problem, and I've determined in my case it's sway's security wrapper that unsets it. If I start sway using /run/current-system/sw/bin/sway, LD_LIBRARY_PATH is set. If I start sway using /run/wrappers/bin/sway, it is not.

I'm not sure what the right thing to do about this is… Security wrappers have a legitimate reason to unset LD_LIBRARY_PATH…

[alyssais]

The sway security wrapper was introduced a month ago in https://github.com/NixOS/nixpkgs/pull/259066, so that would match your timeline if you're using Sway. There's discussion about whether to revert in that PR.

[K900]

The upstream recommended way is to use the pw-jack wrapper, which sets LD_PRELOAD for a specific application.

[alyssais]

It sounds like the answer is "sway should not have a security wrapper" — https://github.com/NixOS/nixpkgs/pull/265358

[sburris0]

I am using sway, yes. However, the other machine I was able to reproduce it on is running GNOME. Maybe something else wasn't right, I'll double-check later today.

[luzpaz]

Heads-up https://github.com/NixOS/nixpkgs/pull/270111

[K900]

That's unrelated.

[ARelaxedScholar]

Just noticed that this wasn't closed yet, this is to say I was able to reproduce the issue on gnome. Using pw-jack reaper worked for me as well.

Not too sure how to fix it.

[sss-create]

From the pipewire package source it seems that pw-jack somehow aliases to $jack? Using $jack reaper does indeed start Reaper but ultimately fails to create a client.

Cannot connect to server socket err = No such file or direct Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done fo JackShmReadWritePtr::~JackShmReadWritePtr - Init not done fo error creating client

[K900]

pw-jack is a wrapper that will LD_PRELOAD the pw-jack library. $jack reaper in a shell will likely just evaluate to reaper, unless you have something setting the jack environment variable.

[andrewbaxter]

Possibly unrelated, but should the pipewire package package jack.pc? I think several other distros do that.

I'm working with an app with buildInputs = [ libjack2 ] but at runtime it needs to load the pipewire equivalent. Using pw-jack probably works, but it would be simpler to have it just link pipewire (if I understand the situation correctly).

[K900]

That sounds very strange. Why would your app care which jack2 implementation is used?

[andrewbaxter]

Fast! And ah, sorry, I just realized I was setting LD_LIBRARY_PATH to jack2 since it's loaded at runtime - I was going to edit when you replied. Anyway, I don't know if that's typical.

But to answer directly, it doesn't. But if it loads the actual libjack2 libraries it'll look for a jack server connection in /dev/shm/jack_default_0_0 or whatever instead of loading the pipewire library and connecting the pipewire way right? Looking at jack_lsp on my non-nix system with ldd it's linked to libpipewire-0.3.so.0 and /usr/lib/libjack.so.0 from the pipewire-jack package, not libjack2's libraries.

My runtime-loading app is currently doing just that, and failing to initiate the pipewire jack connection.

For background, I don't think pipewire jack does the /dev/shm thing, I think it's a higher-level shim and it goes via the /run/user/1000/pipewire-0 socket which does the socket-activated pipewire startup.

[andrewbaxter]

I was just looking at pw-jack and it says

If PipeWire's reimplementation of the JACK client libraries has been installed as a system-wide replacement for JACK's own libraries, then the whole system already behaves in that way, in which case pw-jack has no practical effect.

I didn't find another quote, but that kind of feels to me like pw-jack is a last resort when the pipewire jack libraries haven't been installed system wide (ex: during a gradual migration).

I'll say though, I'm probably way out of my depth here.

[K900]

We never install pw-jack system-wide because it would effectively be a world rebuild.

[andrewbaxter]

Yeah of course, I figured that was the case. But I don't think that's normal and to some degree there will always be paddling upstream (unless/until nix goes pw-first). Maybe that was implicit, but it helps to know and expect it nonetheless.

[K900]

Upstream has no issue with doing the LD_PRELOAD thing, generally.

[andrewbaxter]

Ah, I think I lost my own thread, but I guess basically you're saying the reason jack.pc isn't provided in the pipewire package is because in order for everything to be compatible the expectation is to link to libjack2 then use pw-jack on systems that use pipewire.