Wow. I’ve just stepped out of the office for a rage break because pipewire shat the bed again. It’s amazing how sound seems to be a solved problem 5 or 10 years ago but now it’s just offal.
edit:
$ systemctl status --user pipewire
Failed toconnecttouserscope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using--machine=<user>@.host --user to connect to bus of other user)
That’s not a pipewire problem, that’s a systemctl problem.
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined
The error means systemctl --user can’t reach your user’s D-Bus session because the required environment variables aren’t set. This typically happens when you’ve switched users via su or sudo rather than logging in directly, because htose don’t initialize a full systemd/PAM session. It could also be that your session wasn’t properly initialized by systemd-logind or a number of other things.
Try spawning a proper user session:
Yeah, it was working fine but then it got really hard to use pulse. Just when it was stable, we get a few good years before having to switch to a new unstable thing, since pulse lost support.
I used to have crackling issues with pulseaudio. It needed restarting constantly. Not issue since the switch to pipewire. So my experienced was the absolute opposite of yours.
Depending on the output device it’s still using ALSA underneath (e.g. Bluetooth output instead is given to the BT stack), PipeWire is dealing with managing and routing the audio output rather than actually performing it.
Wow. I’ve just stepped out of the office for a rage break because pipewire shat the bed again. It’s amazing how sound seems to be a solved problem 5 or 10 years ago but now it’s just offal.
edit:
$ systemctl status --user pipewire Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)wheeeee
That’s not a pipewire problem, that’s a systemctl problem.
The error means systemctl --user can’t reach your user’s D-Bus session because the required environment variables aren’t set. This typically happens when you’ve switched users via su or sudo rather than logging in directly, because htose don’t initialize a full systemd/PAM session. It could also be that your session wasn’t properly initialized by systemd-logind or a number of other things. Try spawning a proper user session:
and try the systemctl command again.
Yeah, it was working fine but then it got really hard to use pulse. Just when it was stable, we get a few good years before having to switch to a new unstable thing, since pulse lost support.
I used to have crackling issues with pulseaudio. It needed restarting constantly. Not issue since the switch to pipewire. So my experienced was the absolute opposite of yours.
I never understood why we didn’t just stick with ALSA. OSS was crap, certainly, but ALSA seemed to do the job.
Depending on the output device it’s still using ALSA underneath (e.g. Bluetooth output instead is given to the BT stack), PipeWire is dealing with managing and routing the audio output rather than actually performing it.