You are not logged in.
Why pipewire? Because, it is considerably more reliable, and is a comfortable drop-in replacement for many use-cases.
How to install and start using pipewire?
It's very simple. First it is recommended to install the metapackage
pipewire-audio
which depends on wireplumber (the recommended session manager), pipewire-pulse (to replace PulseAudio), pipewire-alsa (ALSA) and libspa-0.2-bluetooth (for Bluetooth support). Moreover, installing this metapackage will remove pulseaudio to prevent any conflicts between both sound server.
Next, put these lines to your
.xsessionrc
file
wireplumber &
pipewire &
pipewire-pulse &
Attention! Order is important here!
After installing these packages and configuring your xsession, it is recommended to reboot the system.
P.S.
I also recommend installing a package called
pavucontrol
which makes it easy to adjust the audio outputs.
Last edited by stopAI (2023-08-16 16:14:49)
Online
pavucontrol dependence pulseaudio-utils, pulseaudio-utils and pipewire-audio Install together ??
Offline
@stopAI
Thanks for the clear and simple instructions. It works! (in daedalus, not in chimaera)
pavucontrol dependence pulseaudio-utils, pulseaudio-utils and pipewire-audio Install together ??
I just installed pipewire-audio and it automatically removed pulseaudio. It did not remove pavucontrol or pulseaudio-utils. Those can coexist, and they they still work.
Offline
pavucontrol dependence pulseaudio-utils, pulseaudio-utils and pipewire-audio Install together ??
No, the pavucontrol package does not depend on pulseaudio-utils.....for pure set up with alsa, install
pipewire-audio
package...
The
pavucontrol
package can be useful if you want to change order of the audio cards, set your audio card as default, etc.
Last edited by stopAI (2023-11-27 17:02:41)
Online
To the indicated, in my case, I only had to add the following:
pavucontrol-qt (1.2.0-1)
pavucontrol-qt-l10n (1.2.0-1)
Now works.
Thanks!!
Devuan GNU/Linux 5 (daedalus) x86_64
Last edited by leog (2023-11-28 12:45:19)
Soy "por lo general un hombre cuadrado en un agujero redondo", según Alexander Berkman.
Offline
I have got the problem that there is no audio after following this instruction.
There also was no .xsessionrc before. Could this be part of the problem?
I am using devuan 5 (daedalus) 64-bit
kernel Linux 6.1.0-13-amd64 x86_64
mate desktop 1.26.0
Last edited by beginner (2023-11-28 20:57:28)
Offline
I don't have .xsessionrc either. I'm using xfce, so I put the start commands in a script and added that script to my desktop startup applications.
It looks like this. Give it a name, make it executable, put it in your path (/usr/local/bin or ~/bin if you have one) and add that script to your startup apps.
#!/usr/bin/env bash
wireplumber &
pipewire &
pipewire-pulse &
You'll need to exit the desktop and log in again for it to take effect. If you still have no sound, run pavucontrol and check the settings, and/or run alsamixer in a terminal and check the settings - F6 will let you select the audio device.
Offline
Somewhere I read the starting order was important... but mine looks different.
~.xsessionrc
# 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/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
exec /usr/bin/wireplumber &
exec /usr/bin/pipewire-pulse &
I arrived here by attempting to remove pulseaudio altogether, but too many things were silent.
I can't be certain, I think I got it from this forum. HoaS?
Services, rc-update only has alsa-utils at sysinit level.
The only pulse audio packages I have are the ones that would also take most of the install as well, usually libpulse0, plasma-pa, pipewire-pulse, libpulse-mainloop-glib0. But not apulse.
Just my 2cents worth, hoping this may help someone.
pic from 1993, new guitar day.
Offline
.xsessionrc is legacy (X11?) system, not used much, but if you make one it will be used.
pic from 1993, new guitar day.
Offline
Why pipewire? Because, it is considerably more reliable, and is a comfortable drop-in replacement for many use-cases.
How to install and start using pipewire?
...
P.S.I also recommend installing a package called
pavucontrol
which makes it easy to adjust the audio outputs.
Thanks, this worked well, just had to run pavucontrol to pick the correct output once and the setting was saved.
Offline
Thanks, this worked well, just had to run pavucontrol to pick the correct output once and the setting was saved.
It's great to hear that everything is working as it should. By the way, I also use pavucontrol, because it's practically the easiest way to switch sound cards.
Online
Somewhere I read the starting order was important... but mine looks different.
~.xsessionrc
# 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/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 exec /usr/bin/wireplumber & exec /usr/bin/pipewire-pulse &
This appears to work better than stopAI's simpler script.
Just reporting back that GlennW's script seems to work well.
Last edited by mirrortokyo (2023-12-17 16:04:46)
Offline
After installing pipewire-audio and startup script from GlennW
reboot system and log back in to get sound working with pipewire
then its all golden sound from pipewire and freedom from pulseaudio
Offline
Hi, if anyone has timidity working with pipewire on Devuan, I would like to know the details as I haven't yet succeeded in getting it working and am now reliant on my old SoundBlaster Audigy 2 ZS for playing MIDI files.
Offline
Hi, timidity works quite well. I had it installed for playing midi files... and jamming along.
using GS (software samples). I didn't have to do/change anything.
And today is the first time I've actually run timidity "test, check, one, two".
The scripts and links were from another devuan forum subscriber,
HoaS, to whom I respect immensely for his knowledge and willingness to help (as well as his sense of humour).
(I had an Aureal-3D card when I started to use linux... it was great for spatial 3D affects.)
I have alsa-utils alsa-ucm-conf alsa-topology-conf packages installed from the installation process(not me).
I hope you get it working, I never heard midi so nice. :-)
pic from 1993, new guitar day.
Offline
Funnily enough,
timidity somefile.mid
(ie using default audio output) worked
Offline
Somewhere I read the starting order was important... but mine looks different.
This appears to work better than stopAI's simpler script.
Just reporting back that GlennW's script seems to work well.
That script is a simplified version of what Gentoo and Slackware (and likely other non-systemd distros) are using to start pipewire.
PW doesn't daemonise properly, exit with the user's session, or manage it's own instances and ordering, instead relying on systemd user units for all that.
The 1 second sleep is required for reliability, and killing pipewire processes avoids not having sound after a logout -> login (unless you have elogind and KillUserProcesses=yes, which kills everything).
Personally I got rid of all that hacky mess, and am 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, but also neatly solves the "pipewire doesn't exit with session" problem.
Last edited by steve_v (2024-01-07 16:25:59)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
Steve_v, I thought wireplumber was taking over the server-side of audio (and multimedia) i/o.
It's still very new to me...
Just to be clear, That ~.xsessionrc script was found here on this forum.
I stand on the shoulders of giants. It would be awfully quiet here with out them.
pic from 1993, new guitar day.
Offline
Thanks for the info, everyone. I was dreading having to install PA, but some applications absolutely require it.
Does anyone know if PW supports CLI control in the same way as PA, for example, with pactl & pacmd? I need it for my volume hotkey scripts, among other things. More on PA CLI control here:
https://shallowsky.com/linux/pulseaudio … -line.html
Offline
Does anyone know if PW supports CLI control in the same way as PA, for example, with pactl & pacmd?
When using the PipeWire PulseAudio replacement server, all of pactl commands should work as usual. Some of the pactl commands have native PipeWire equivalents that will also work without pipewire-pulse.
More info here:
Online
Thanks stopAI! I didn't realize that pipewire-pulse was a separate program from pipewire itself. Apparently it can even send audio over the network, which is something I just happened to be looking for today:
https://gitlab.freedesktop.org/pipewire … rk-support
Offline
I didn't realize that pipewire-pulse was a separate program from pipewire itself.
Yes, pipewire-pulse is dependencies of pipewire-audio meta package. It is recommended to install this metapackage
pipewire-audio
which depends on wireplumber (the recommended session manager), pipewire-pulse (to replace PulseAudio), pipewire-alsa (ALSA) and libspa-0.2-bluetooth (for Bluetooth support).
Moreover, installing this metapackage will remove pulseaudio to prevent any conflicts between both sound server.
Online
I found that wireplumber wasn't running after some updates today so I added another wait loop in @GlennW's script and it seems to work now:
# 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/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
exec /usr/bin/wireplumber &
# wait for wireplumber to start before attempting to start pipewire-pulse
while [ "$(pgrep -f /usr/bin/wireplumber)" = "" ] ; do
sleep 1
done
exec /usr/bin/pipewire-pulse &
What is the "best practice" for processes that need to be running in the background before another process that also needs to be running in the background is started? This seems to be a bit of a rough hack.
Last edited by mirrortokyo (2024-01-12 06:31:49)
Offline
This seems to be a bit of a rough hack.
It is, and writing custom shell hacks for every user-session "daemon" that doesn't bother to behave like a daemon because systemd user units exist isn't a particularly elegant or sustainable solution.
If Devuan is going to transition to pipewire following upstream Debian, we're going to need a better answer than "user finds random script / autostart / .xinitrc hints on the 'net" for starting and stopping its services.
IMO some kind of process supervisor (be it part of an init system or standalone) is the only realistic (and reliable) option, and I already mentioned one possibility. Another might be adapting supervise-daemon or runits runsvdir, or running dinit in a user-session context.
This BS is only going to become more common, pipewirwe is just the thin end of this particular freedesktop/redhat/ibm wedge.
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
In 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.
$ daemon --list --verbose
cdemu is running (pid 4577) (client pid 4578)
pipewire is running (pid 4573) (client pid 4574)
pipewire-pulse is running (pid 4568) (client pid 4572)
pipewire-wireplumber is running (pid 4547) (client pid 4549)
systembus-notify is running (pid 4583) (client pid 4587)
If you don't want pipewire noise in your xsession log (or want it in it's own logfile), daemon can fix that too with the --output, --stdout, and --stderr switches.
The cost for all this convenience is ~170KB of memory per managed process (on-par with supervise-daemon). Make of it what you will. As much as I like shell, IMO this is a much cleaner solution.
Last edited by steve_v (2024-01-23 09:58:55)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
Sounds very intelligent to me, Steve (although I never run pipewire).
Offline