You are not logged in.
Allow me to add some fuel to the fire, or maybe start something we can build on in common: https://github.com/davesp/start_user_pipewire
Offline
Why use Microsoft's server for FOSS ?
Why not git.devuan.org ?
Or codeberg.org ?
Offline
I've been boycotting github for years . . . MS can kiss my skinny behind. ![]()
Offline
OT: I didn't so much "choose" GitHub as "defaulted" to it.
It's familiar, and I already had it set up.
I didn't notice any Microsoft branding (nor was I looking for any).
GitHub didn't force me to insert any Microsoft-specific code, or force me to use Windows or Edge.
If they're paying for GitHub to exist and are hosting OSS without forcing authors to "bend to their will", isn't that good for OSS?
That's why using GitHib wasn't a big deal for me. But, since this is arguably a Devuan-specific issue, the repo has been moved from GitHub to "https://git.devuan.org/davesp/start_user_pipewire".
Last edited by davesp (2025-11-14 23:29:02)
Offline
I just tried your script on my setup and it works.
Thanks davesp.
Offline
Just a quick question, it seems as though pipewire is running via the user, is this check correct?
user1 being my login name.
~ $ ps -aux | grep 'pipewire\|wireplumber'
user1 2081 0.0 0.0 104188 12720 tty1 Sl 09:45 0:00 /usr/bin/pipewire
user1 2084 0.5 0.0 481776 19648 tty1 SLl 09:45 0:03 /usr/bin/wireplumber
user1 2087 0.4 0.0 105960 14652 tty1 SLl 09:45 0:03 /usr/bin/pipewire-pulseLast edited by HardSun (2025-11-14 23:59:59)
Offline
[Edited to update testing info.] Thanks for sharing the script. I found it easy to read and to understand what it was doing, which is much more than I can say about many of the scripts included with Debian. ![]()
A note to anyone not running elogind: you will need to manually set the value of XDG_RUNTIME_DIR to a directory which you own to get the pipewire daemon to start successfully. It's not enough to use a system directory where you have write permissions, such as /tmp, you must actually own it. Something like /tmp/pw will work. [Edit: I initially said /tmp/pulse, but that already exists!] I'm not sure yet how pipewire handles exit; you may need to clean up after it. It's probably worth noting that the startup script did not pass through the error messages from pipewire to the terminal when it failed. I had to start pipewire manually to figure out why it was failing. If anyone else runs into trouble, I suggest you try that first.
After I fixed this issue, the three daemons started successfully, and I confirmed monitor audio was working in OBS Studio (obs requires PulseAudio support for monitoring.) The only drawback was routing: I only saw a single PA input and output (hello feedback!) Hopefully, that's something I can fix through the configuration files.
Last edited by stultumanto (Yesterday 10:17:05)
Offline
stultumanto, that's a good find. Just now, I pushed an update which captures stderr from each binary launch, and says where to look if that launch failed.
I don't have XDG_RUNTIME_DIR set locally; are you able to un-set XDG_RUNTIME_DIR and re-run the script to see if the change would help debug the issue?
Offline
HardSun: Those are the binaries which are expected to be running. Is your audio not working?
Offline
@davesp
its working, i was just curious if i was running it correctly, i put it in .xinitrc to autostart via startx.
I also locally set $XDG_RUNTIME_DIR as i dont use elogind only seatd.
Last edited by HardSun (Yesterday 23:55:02)
Offline
just cancel pipewire and use alsa only + jack every so often, this is literally bloating the desktop with the bloatware of pipewire as if the poettering bloatware of pulseaudio wasn't bad enough, maybe we should all go to a real OS like OpenBSD that has a proper audio stack and system.
Offline