Using Pipewire instead of Pulseaudio in Slackware 15
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Thanks! ZhaoLin1457 is the man! My QMPlay2 now has Alsa, PipeWire, and PulseAudio!
Thanks for your kind words, but permit me to doubt that my modest contributions have something to do with your QMPlay2 abilities to use ALSA, PipeWire, and PulseAudio.
In fact, the daemon supervisor created by @raforg on this setup invented by mine, together with the XDG autostart, just emulates more of less the systemd's behavior for its "user target" daemons.
In fact, this has nothing to do with PipeWire, does not influence its behavior in anyway, and just like we handle now the three PipeWire daemons, same we can do with another programs designed to be used by systemd as "user target" daemons.
For example, those VPN daemons which requires the systemd, because they are supposed to be run as "user target" daemons.
If you ask what's an "user target" daemon, as ridiculous as it looks, it's just an ordinary program, with no abilities to behave a daemon (like PulseAudio, for example) while they are supposed to be run on background and controlled by systemd on their life cycle.
Essentially, the systemd starts them on user login, keeps them alive (one instance per user) and stops them on user logout.
The PulseAudio is a true daemon, it knows how to go in background, how to not start more than one instance per user and even how to quit itself on user logout. But, the PipeWire daemons has no idea how to do those things and that's why we need the help of @raforg's daemon to handle them.
Any other "simpler" solution (as those vehiculated on this thread) are partial solving of the requirements and sooner or later they will end on issues. At least this is my humble opinion, as someone who experimented since more than a half of year with various methods to run on Slackware those "user daemons" designed for systemd.
True, there's also the design made by @LuckyCyborg, which probably emulates much better the Slackware init system for this "user" side, but it is also way more complicated, as he agrees himself.
For your amusement, here is one of the three scripts used by him for those PipeWire daemons:
Code:
#!/bin/sh
#
# Pipewire startup script for Slackware Linux
# The log file path;
LOGFILE="/tmp/pipewire-${USER}/pipewire.log"
#LOGFILE="${HOME}/.local/share/pipewire/pipewire.log"
# The PID file path:
PIDFILE="/run/user/${UID}/pipewire.pid"
pipewire_start() {
if [ -s $PIDFILE ]; then
PID=$(cat $PIDFILE)
if ps -p $PID > /dev/null; then
echo "Pipewire appears to be already running?"
exit 1
fi
fi
rm -f $PIDFILE
mkdir -p $(dirname $LOGFILE)
echo -n "Starting pipewire server..."
PIPEWIRE_LOG=$LOGFILE /usr/bin/pipewire >/dev/null 2>&1 &
if [ $? -eq 0 ]; then
PID=$!
echo "$PID" > $PIDFILE
echo " done"
else
echo " failed"
exit 1
fi
}
pipewire_stop() {
if [ ! -s $PIDFILE ]; then
echo "$PIDFILE does not exist or is empty."
rm -f $PIDFILE
exit 1
fi
PID=$(cat $PIDFILE)
rm -f $PIDFILE
if ps -p $PID > /dev/null; then
mkdir -p $(dirname $LOGFILE)
echo -n "Stopping pipewire server..."
kill $PID >/dev/null 2>&1
while [ -d /proc/$PID ]; do
sleep 1
echo -n "."
done
echo " done"
else
echo "Pipewire server is not running."
exit 1
fi
}
pipewire_restart() {
pipewire_stop
sleep 1
pipewire_start
}
case "$1" in
start)
pipewire_start
;;
stop)
pipewire_stop
;;
restart)
pipewire_restart
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
Now, going back to your experiences with abilities of using ALSA, PipeWire and PulseAudio while running PipeWire audio server, I think you should say thanks to Mr. Hameleers, who's the first who packaged the PipeWire for KTown, then to Mr. Volkeding who magisterially integrated the PipeWire on Slackware-current and also built the FFMPEG with native PipeWire support.
Yes, looks like that PipeWire started to blend on the operating system, and honestly I do not know which many packages from Slackware-current are now capable to use the native PipeWire APIs.
But, like I said previously, this design imagined by mine has nothing to do with this, it has the simple purpose of babysitting the PipeWire daemons just like systemd would have did.
Last edited by ZhaoLin1457; 04-21-2021 at 04:10 PM.
Thank you everyone! And thanks to whoever coded Pulse to allow for this (code from default.pa and system.pa):
Code:
### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
#load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev support)
load-module module-detect
.endif
I have to press ALSA twice in QMPlay2 to switch to it. I have to wait a few seconds after switching to it the first time to click apply again to get it to work.
Distribution: Slackware 15.0 x64, Slackware Live 15.0 x64
Posts: 618
Rep:
Quote:
Originally Posted by notzed
It's only "simple" here because most (all?) current software is written to use the pulseaudio client library, and pipewrite provides a compatible pusleaudio server implementation. So this lets one use the pipewire framework for sound instead of pulseaudio without having to rewrite any of the client (user) software to use it's apis. While most application software has alsa output, not all of it does and with some it might require special building options. And if they don't have an alsa output option you would have to write one which may not be easy and they probably wont accept as a patch for either.
slackware-current removed the pure-alsa module a few months ago and so it wont be available in 15. I use a combination of plain alsa and pipewire with the pipewire-pulse daemon and disable pulseaudio because it's not something i will let run on my computers. I use a simpler approach than the one here, I set the daemon-binary in /etc/pulse/client.conf to run pipewire, and have /etc/pipewire/pipewire.conf start the pipewire-pulse service. It just seems to work with no hassles, and for this computer i'm the only user and always logged in.
I have a headless PC that plays music and the setup described here is worthless since I don't log into any graphical session to use it. But for that I just use alsa because I wrote the music player it's running, so that point is moot.
Okay, I kinda, sorta understood this answer, and appreciate it. I guess LuckyCyborg couldn't figure out, with all that super-intelligence he believes he has, that I wasn't flaming anything but was asking a simple question...twice. I figure he got pissed off because I took away from him patting himself on the back so much.
However, I do not believe that this does mean that the PulseAudio will be removed from the distro.
I imagine that there will be a PulseAudio package without its own audio server, containing only the libraries, headers and the tools.
In fact, probably the splitting the PulseAudio server in a separate package is a great idea even for today.
I think I was a little hasty - the completely change of the config format is still possible in pipewire, I have come across this myself recently. Of course, it's a bit early to accept pipewire by default in Slackware, as it's not well-established yet, but there isn't much choice, imo. That does not negate the quality of Pulsaudio 2.0.
Probably, it would be wise to have pulsaudio libs as separate package in the distribution and raise the pipewire version during the lifetime of the release - it is difficult to come up with something more suiting.
Last edited by lagavulin16; 04-23-2021 at 12:45 PM.
Just a few words to thank you guys for your work
I recently apply your "HowTo" and everything works wonderfully (speakers, bluetooth -whatever wireless earphones-, taskbar tooltips)
There's a small typo in the "Setting up PipeWire" section - after mentioning pipewire config files being stored in /etc/pipewire, we're invited to open /etc/pipewire.conf. It should be /etc/pipewire/piewire.conf.
There's a small typo in the "Setting up PipeWire" section - after mentioning pipewire config files being stored in /etc/pipewire, we're invited to open /etc/pipewire.conf. It should be /etc/pipewire/piewire.conf.
chris
Also there's a small issue on this wonderful post: he explained how to start the PipeWire daemons (and this was never an issue), but not how to stop them on user logout, and how to ensure that a single instance of each of three of them is started per user.
And this is freaking important, because the PipeWIre daemons are ordinary programs, which does not know like PulseAudio, how to quit themselves on user logout or to no start a second instance if it is already started.
So, the solution proposed will results on zombies, with not so spectacular effects like NO SOUND or even full desktop crashes, if the user logins/logout/logins or even starting from console with startkwayland or startx, then shutdown the desktop and starting again.
How @kingbeowulf loves to note dates, I just humbly remembered that on Nov 27, 2020 I started the discussion with @raforg about adding the elogind support on a particular way, on his daemon. Which ended with his agreement to add the ability to quit on user logout, finally ending with this little daemon added to Slackware:
Also there's a small issue on this wonderful post: he explained how to start the PipeWire daemons (and this was never an issue), but not how to stop them on user logout, and how to ensure that a single instance of each of three of them is started per user.
And this is freaking important, because the PipeWIre daemons are ordinary programs, which does not know like PulseAudio, how to quit themselves on user logout or to no start a second instance if it is already started.
So, the solution proposed will results on zombies, with not so spectacular effects like NO SOUND or even full desktop crashes, if the user logins/logout/logins or even starting from console with startkwayland or startx, then shutdown the desktop and starting again.
...
In my defense, pulseaudio is doing the same thing. Still a good point since pulseaudio has a -k option but I'm not finding an equivalent for pipewire. Since pulse/pipe run as servers this not technically an issue. Clients can connect to the Server whenever they want regardless of the running desktop. There are also options for doing this over the network which is probably why the daemons don't care if X dies.
I wrote that post for a previous version of pipewire so it doesn't take into considering recent changes upstream. I'm still running it but I had to fiddle with the media-session daemon as well. pipewire is still in a state of rapid development so you need to keep an eye on any updates you pull in for major changes.
Well, I do use Bluetooth for my stereo receiver and I can report PipeWire works with it beautifully. Pipewire correctly assumes I want my stereo receiver turned on when I bring my system out of sleep/login/start my system. Many thanks to Wim Tayman for its creation!
Last edited by 1337_powerslacker; 05-22-2021 at 06:46 AM.
Reason: Too many its.
I haven't been able to achieve good quality recording using Bluetooth headphones microphone with PA so I compiled PipeWire from master and ran it today but Bluetooth microphone is still not working as I expected. I have set
Code:
bluez5.msbc-support = true
in /usr/share/pipewire/media-session.d/bluez-monitor.conf but mSBC is not showing up in pavucontrol or pw-dump and only CVSD is available. User LuckyCyborg has said here https://www.linuxquestions.org/quest...ml#post6243907 that Bluetooth microphone works well for them with Pipewire. I run Linux 5.10.31. I can't say if my Bose QC35 II headphones support mSBC codec but if they didn't how would they work so well with Android? I use a very cheap Bluetooth dongle but I heard that mSBC support does not depend on hardware. Has anybody else tried using Bluetooth microphone with Pipewire and could report the results?
I haven't been able to achieve good quality recording using Bluetooth headphones microphone with PA so I compiled PipeWire from master and ran it today but Bluetooth microphone is still not working as I expected. I have set
Code:
bluez5.msbc-support = true
in /usr/share/pipewire/media-session.d/bluez-monitor.conf but mSBC is not showing up in pavucontrol or pw-dump and only CVSD is available. User LuckyCyborg has said here https://www.linuxquestions.org/quest...ml#post6243907 that Bluetooth microphone works well for them with Pipewire. I run Linux 5.10.31. I can't say if my Bose QC35 II headphones support mSBC codec but if they didn't how would they work so well with Android? I use a very cheap Bluetooth dongle but I heard that mSBC support does not depend on hardware. Has anybody else tried using Bluetooth microphone with Pipewire and could report the results?
Bose QC35 II + pipewire user here.
Code:
➜ ~ pw-cli info all | grep bluez5.codec
* api.bluez5.codec = "sbc"
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.