840
systemctl status --user pipewire (lemmy.world)
submitted 7 months ago by to c/linuxmemes@lemmy.world
106 comments fedilink hide all child comments
 

you are viewing a single comment's thread
view the rest of the comments
[–] 16 points 7 months ago* (last edited 7 months ago) (8 children)

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

  • permalink
  • fedilink
  • source
  • hideshow 8 child comments
    •
  • [–] 9 points 7 months ago (2 children)

    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:

    sudo machinectl shell your_username@

    and try the systemctl command again.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 7 months ago (1 child)

    typically happens when you’ve switched users via su or sudo rather than logging in directly,

    1. I wish typical scenarios were the only ones we had -- it'd be a trivial solution.
    2. This is a largely unmolested install because I don't want to be debugging my desktop. If I had a point other than whingeing, here, that would be it: when the default, vanilla, least-tuned setup falls over on the regular, then it's fundamentally a failure at its "you had one job" task.
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 7 months ago

    If it's consistently breaking then your distro is messing up something. Bad defaults, broken scripts, etc.

    The problem is that the environment variables are expected to be there and they are not there.

    So, if you're not doing something odd, then your distro is pushing misconfigurations or some other piece of software is interfering with your environmental variables. Whatever the vanilla setup for your distro is, it is not setup correctly.

    I do agree that it's frustrating, just aim the ire in the right direction... whoever configured your system's defaults.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 7 months ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 7 months ago (1 child)

    I never understood why we didn't just stick with ALSA. OSS was crap, certainly, but ALSA seemed to do the job.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 5 points 7 months ago

    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.

  • permalink
  • fedilink
  • source
  • parent