How to: Devuan 5 Daedalus an pipewire

mirrortokyo · 2024-01-23 15:47:50

Thanks @steve_v, one last thing - you should have mentioned that /usr/bin/daemon is in package daemon.

steve_v · 2024-01-23 18:09:33

I kinda did, a few posts earlier in this thread:

steve_v wrote:

using daemon to manage pipewire (and cdemu, which has the same problems). Binding to the user session requires [e]logind and backporting daemon from unstable

daemon has very few dependencies, so a backport is trivial.

Last edited by steve_v (2024-01-23 18:11:56)

ffp · 2024-02-23 18:00:29

Hello friends, I tried the implementations listed here on my Dell Latitude 7480 laptop and while they do work, I sometimes had to reboot my laptop a few times to get working audio or manually kill and start the pipewire processes from terminal.
I found a different solution which worked for me and I wanted to share it with you too in case you have a similar problem:

In /etc/X11/Xsession.d/ create a file and call it 98-pipewire and put the following script into it:

#!/bin/bash

# We need to kill any existing pipewire instance to restore sound
pkill -u "${USER}" -fx /usr/bin/pipewire-pulse 1>/dev/null 2>&1
pkill -u "${USER}" -fx /usr/bin/pipewire-media-session 1>/dev/null 2>&1
pkill -u "${USER}" -fx /usr/bin/wireplumber 1>/dev/null 2>&1
pkill -u "${USER}" -fx /usr/bin/pipewire 1>/dev/null 2>&1

exec /usr/bin/pipewire &

# wait for pipewire to start before attempting to start related daemons
while [ "$(pgrep -f /usr/bin/pipewire)" = "" ]; do
        sleep 1
done

if [ -x /usr/bin/wireplumber ]; then
	exec /usr/bin/wireplumber &
elif [ -x /usr/bin/pipewire-media-session ]; then
	exec /usr/bin/pipewire-media-session &
fi

[ -f "/usr/share/pipewire/pipewire-pulse.conf" ] && exec /usr/bin/pipewire-pulse &

And with this I get audio on every reboot so no more restarting my laptop multiple times.

The only issue I had after doing this is that sometimes the audio was a bit choppy.
I found a solution on the Debian wiki but it had to be applied on every boot so I did this:

In /usr/share/pipewire/pipewire.conf I uncommented and changed the settings

default.clock.allowed-rates = [ 44100 48000 ]
default.clock.quantum       = 2048
default.clock.min-quantum   = 2048

And after rebooting this was solved for me too. I hope this can help you as well!

nixer · 2024-02-27 17:41:55

I hope this can help you as well!

Thank you ffp! This got pipewire working on a daedalus install that has been dist-upgraded from ascii > beowulf > chimaera > to daedalus!

nixer · 2024-02-29 18:29:04

steve_v, would you please elaborate how you used daemon to run the commands you quoted? Specifically, where did you put these commands and how did you "autostart" them?

In 3 autostart files (or wherever else you might want them).

I have tried to run them from /etc/rc.local. I tried to add your commands to the /etc/daemon.conf file and tried to add them individually to /etc/daemon.conf.d folder. Try as I might, I can only get the "daemon --list --verbose" command to output "No named daemons are running". I was just trying things because my web searching on how to use "daemon" was not very successful.

But, I added the three commands to a file in /usr/local/bin and set it to autostart upon login with xfce and pipewire does work. But I still get the "No named daemons are running" output from the terminal.

I have tried this on both daedalus and ceres and I get the same results. Any additional information would be appreciated.

Last edited by nixer (2024-02-29 18:30:04)

mweishaar · 2024-03-23 23:53:14

@nixer I couldn't get it to work either, but when I run the daemon command from the terminal I get "unrecognized option '--bind' " which would explain why it isn't working. I have daemon 0.8-1+b1 from backports. But re-reading, steve_v said unstable backports.
I'll have to look up how to install from unstable, I usually don't mess with that.

Maybe you have the same issue.

abower · 2024-04-19 23:38:39

Another might be adapting supervise-daemon or runits runsvdir, or running dinit in a user-session context.

Thanks for the idea, steve_v! I just set up a runit-based solution. It seems yours has a more sophisticated lifecycle integration with the session/login manager (I'm not so clued up on that stuff) but here's what I have done anyhow:

The runit scripts may be found at runit-desktop - they can be unpacked to ~/.xusersvc. Here's a sample:

#!/usr/bin/sh

SVDIR=$(dirname ${PWD}) sv start pipewire || exit 1

set -e
exec 2>&1
echo "Starting ${PWD##*/}..."

exec /usr/bin/pipewire-pulse

Then I have an XFCE Application autostart entry (cat "~/.config/autostart/User runsvdir.desktop":

[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=User runsvdir
Comment=Start user runit services
Exec=runsvdir .xusersvc
OnlyShowIn=XFCE;
RunHook=0
StartupNotify=false
Terminal=false
Hidden=false

and we are away (sv status .xusersvc/*)!

run: .xusersvc/pipewire: (pid 19758) 1035s; run: log: (pid 19757) 1035s
run: .xusersvc/pipewire-pulse: (pid 19778) 1035s; run: log: (pid 19769) 1035s
run: .xusersvc/wireplumber: (pid 19771) 1035s; run: log: (pid 19768) 1035s

With log files sitting in ~/.xuserlog/*/current:

024-04-19_22:58:50.32626 ok: run: pipewire: (pid 19758) 0s
2024-04-19_22:58:50.32632 Starting pipewire-pulse...
2024-04-19_22:58:51.58468 [W][06850.910390] default      | [   snap-policy.c:   71 pw_snap_get_audio_permissions()] snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap audio permissions won't be honored.

Supervision seems to end satisfactorily on session exit although I did also try a logout hook that ran pkill -HUP on the user's runsvdir but I'm not sure what it gained.

Fortunately it seems the services create their own sockets when systemd activation is absent and we don't need to worry about the various .socket units.

(Also, my first post although I have used the OS for some years - thank you Devuan people!)

steve_v · 2024-04-20 10:03:53

nixer wrote:

where did you put these commands and how did you "autostart" them?

In my case they're just desktop files in /etc/xdg/autostart. Actually running them is up to an XDG compliant DE.
Anywhere else that has them start after session login should work just as well though.

I still get the "No named daemons are running" output from the terminal.

Probably can't find any pidfiles, '--list' also needs the same '--pidfiles' argument you used when starting them, or a default set in /etc/daemon.conf

mweishaar wrote:

"unrecognized option '--bind'"

Yeah, elogind hooks need a version from unstable. >=0.8.2 IIRC.
See the "simple backport creation" debian wiki entry for an easy guide.

Last edited by steve_v (2024-04-20 10:05:49)

mweishaar · 2024-04-23 21:53:02

I just added teh aformentioned script (in ~/bin) to XFCE's Application Startup under Session and Startup.

No issues pipewire is running without a hiccup.
I do only reboot when necessary, which isn't very often. But I did a few times just to make sure it was working.

GlennW · 2024-04-23 22:30:18

@mirrortokyo: HoaS's scripting solution may be found all over the net, I wouldn't know where to start, am just the messenger.

I like your solution Steve, looks nice and tidy and repeatable from install to install.

Thank you

mirrortokyo · 2024-04-26 09:02:57

@GlennW my current solution is:

~/.xsessionrc

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-pulse /usr/bin/pipewire-pulse
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber

Currently working fine, but if the packages related to pipewire get upgraded, one may need to exit the desktop session, and if sound isn't working on logging in again either do:

init 1

then

exit

to get the desktop session login manager up again,

or in extreme cases shutdown the computer and reboot.

Last edited by mirrortokyo (2024-04-26 09:10:16)

EDX-0 · 2024-04-28 00:57:18

fun, my current solution was to not even bother with daemon but instead write a whole program to do management of user level services independient of any init...

tho i need to work on it.
https://github.com/eylles/shed

i do not use a desktop environment so instead of a regular autostart i use this program, there is a lot more that i need to do since i know next to nothing about some stuff and shed is written off my limited understanding of how sysvinit works.

thanks to shed all i need to have these 3 simple files:

pipewire:

NAME=pipewire
EXEC=/usr/bin/pipewire

pipewire-pulse:

NAME=pipewire-pulse
EXEC=/usr/bin/pipewire-pulse

wireplumber:

NAME=wireplumber
EXEC=/usr/bin/wireplumber

and shed will do the rest, i can restart any individual binary if needed or all 3.

Last edited by EDX-0 (2024-04-28 16:27:57)

soren · 2024-05-26 03:16:12

steve_v wrote:

FWIW (in case I haven't mentioned it already elsewhere, which I probably have) my current solution is daemon, and these three lines:
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-pulse /usr/bin/pipewire-pulse
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber
n 3 autostart files (or wherever else you might want them).
Order no longer matters and sleep / while loop hacks are eliminated, because --respawn.
Pipewire not exiting with the user session is fixed (without pkill hacks), because --bind.
Pipewire not doing any of the other things a daemon should do (like writing a pid file or detaching from stdout and forking into the background) is also fixed, and --name and --pidfiles allow for e.g.

As quoted from steve_v above this has worked for me up until recently, I found out that --bind flag is no longer workin using daemon, can you confirm steve or anyone else? So i took that out of the commands and now it is working. Im on deadalus stable.

Also can anyone suggest a better way to make pipewire/pulse whatever use the audio sink that i want as default? Currently im just using a command to make the bluetooth speaker default sink as follows in xfce4. Im too used to alsa and cant figure this new pipewire stuff out, but i need to so i can make the new bluetooth speaker work.

sleep 10s && pactl set-default-sink "bluez_output.10_94_UE_EC_C0_5E.1"

Otherwise pipewire/pulse automatically sets the hdmi alsa sink from the monitor and i cant seem to get pactl to keep my setting over reboots or logouts.

Last edited by soren (2024-05-26 03:17:12)

soren · 2024-05-26 03:32:44

Just to add a bit more info to my previous post. I found the below relating to the --bind flag on daemon. Not sure what this means, but i do have elogind running as im now using xfce4.

If the `--bind` option was supplied, on systems with *systemd-logind* or
*elogind*, the client process will be terminated when the user logs out.

https://www.libslack.org/daemon/README

RedGreen925 · 2024-12-12 19:52:25

A necro post to say thanks for the solution to getting even more of that scumbags code off my machine. Did not know I was even running it until I saw pulseaudio getting updated. Search and found this page with one of the easiest solutions I have ever done I do believe. Create an .xsessionrc with the contents from above the first one with the sleep 1 posting in it, install the pipewire-audio that removes the pulseaudio package then reboot to have working audio on the pipewire server. Perfect thanks again.

mirrortokyo · 2024-12-14 09:31:26

Something broke again, I can't start wireplumber from .xsessionrc after doing an upgrade to libglib2.0-0t64 2.82.4-1, it works fine with liblib2.0-0t64 2.82.3-2. (I can start wireplumber from the command line though).

.xsessionrc wireplumber start-up command:

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber

Reported as Debian bug #1089865.

EDIT - thanks to @steve_v for the suggestions. I should have enabled debugging by using daemon -d invocation of the pipewire programs run from .xsessionrc and have noted this as a comment in the .xsessionrc file.

For some unknown reason, after upgrading libglib related packages again I could not reproduce the problem and I have asked for the Debian bug report to be closed.

Last edited by mirrortokyo (2024-12-15 09:03:35)

steve_v · 2024-12-15 03:53:56

Why not start by enabling some logging and doing at least basic troubleshooting yourself? All I see here is "it stopped working".
Use of log files is in the daemon manual, and the very least, try the same command you're using in xinitrc manually and see if it's throwing any errors on stdout/stderr.

Nobody is psychic, and that debian bug report is so devoid of information as to be practically useless. Are you really running sid/experimental? If so, you should be prepared for random borkage and prepared to do some digging... That's why it's called "experimental".

And no, no I'm not going to ~~look into this~~ hose any of my systems by enabling the sid or experimental repos. If you want an install that doesn't regularly break after package updates, run stable (and backport things you want from sid yourself).

greenjeans · 2024-12-15 05:39:41

Am I the only old geezer who runs pure ALSA and nothing else?

steve_v · 2024-12-15 07:16:29

Quite possibly

While I do run plain ALSA on systems that have no need for a sound-server, something of the latter nature (i.e pulseaudio or pipewire) is practically a requirement if you want "modern" GUI-centric on-the-fly source/sink and sample-rate switching for things like bluetooth audio peripherals.
ALSA can of course do most of that itself, but it's somewhat awkward and requires a bit of experimentation and messing about in poorly-documented configuration files... Which few can be bothered with any more, because much like the extended "I just copy-paste and hope it works" in this thread, "If I can't click on it, it doesn't exist" is apparently a thing.

Pipewire is also essentially unavoidable if you want desktop audio/video capture in a wayland session, and as with all the other functionality still missing from the wayland spec, that's the way freedesktop intended it.

Last edited by steve_v (2024-12-15 07:17:01)

PedroReina · 2024-12-15 08:53:29

greenjeans wrote:

Am I the only old geezer who runs pure ALSA and nothing else?

You're not . I keep using pure ALSA on all my desktop systems. So far, I don't need any layer on it. Sometimes I have to fiddle with configuration files, but everytime successfully.

golinux · 2024-12-15 15:34:28

Add me to that list! But then I don't use that function often and hardware is generic.

Altoid · 2024-12-15 17:06:52

Hello:

greenjeans wrote:

... the only old geezer who runs pure ALSA and nothing else?

Let's see ...

Old ☑
Geezer ☑ -> actually, one of the US english slang terms for 'old'.
Pure ALSA ☑

Yes, add me to the list.

golinux wrote:

Add me to that list!

Nope.
Nocando Miss ...

Just using pure ALSA is not enough to qualify for that list.

Best,

A.

golinux · 2024-12-15 17:50:52

@Altoid . . . You are definitely the grand-master of much ado about nothing and the point of your latest effort completely escapes me. Plonk . . .

greenjeans · 2024-12-15 18:04:41

He's complimenting you, he's saying you're not old or a geezer. I agree.

Only config i've ever had to do with ALSA, is add an .asoundrc in some cases, on machines that have more than one sound device (i.e. HDMI) and on the newest version to use the built-in equalizer:

ctl.equal {
	type equal;
}

pcm.plugequal {
    type equal;
	slave.pcm "plughw:0,0";
}

pcm.equal{
    type plug;
    slave.pcm plugequal;

New command to invoke it, I used it in a menu entry:

'lxterminal --geometry=100x30 -e alsamixer -D equal'

quickfur · 2024-12-16 03:41:28

I've always used pure ALSA. The newer wannabe replacements / layers on top just add needless complication of little value to my use case. So I just don't bother. ALSA works well enough for what I need to use it for.

The officially official Devuan Forum!

#26 2024-01-23 15:47:50

Re: How to: Devuan 5 Daedalus an pipewire

#27 2024-01-23 18:09:33

Re: How to: Devuan 5 Daedalus an pipewire

#28 2024-02-23 18:00:29

Re: How to: Devuan 5 Daedalus an pipewire

#29 2024-02-27 17:41:55

Re: How to: Devuan 5 Daedalus an pipewire

#30 2024-02-29 18:29:04

Re: How to: Devuan 5 Daedalus an pipewire

#31 2024-03-23 23:53:14

Re: How to: Devuan 5 Daedalus an pipewire

#32 2024-04-19 23:38:39

Re: How to: Devuan 5 Daedalus an pipewire

#33 2024-04-20 10:03:53

Re: How to: Devuan 5 Daedalus an pipewire

#34 2024-04-23 21:53:02

Re: How to: Devuan 5 Daedalus an pipewire

#35 2024-04-23 22:30:18

Re: How to: Devuan 5 Daedalus an pipewire

#36 2024-04-26 09:02:57

Re: How to: Devuan 5 Daedalus an pipewire

#37 2024-04-28 00:57:18

Re: How to: Devuan 5 Daedalus an pipewire

#38 2024-05-26 03:16:12

Re: How to: Devuan 5 Daedalus an pipewire

#39 2024-05-26 03:32:44

Re: How to: Devuan 5 Daedalus an pipewire

#40 2024-12-12 19:52:25

Re: How to: Devuan 5 Daedalus an pipewire

#41 2024-12-14 09:31:26

Re: How to: Devuan 5 Daedalus an pipewire

#42 2024-12-15 03:53:56

Re: How to: Devuan 5 Daedalus an pipewire

#43 2024-12-15 05:39:41

Re: How to: Devuan 5 Daedalus an pipewire

#44 2024-12-15 07:16:29

Re: How to: Devuan 5 Daedalus an pipewire

#45 2024-12-15 08:53:29

Re: How to: Devuan 5 Daedalus an pipewire

#46 2024-12-15 15:34:28

Re: How to: Devuan 5 Daedalus an pipewire

#47 2024-12-15 17:06:52

Re: How to: Devuan 5 Daedalus an pipewire

#48 2024-12-15 17:50:52

Re: How to: Devuan 5 Daedalus an pipewire

#49 2024-12-15 18:04:41

Re: How to: Devuan 5 Daedalus an pipewire

#50 2024-12-16 03:41:28

Re: How to: Devuan 5 Daedalus an pipewire

Board footer