Using Pipewire instead of Pulseaudio in Slackware 15

LuckyCyborg · 10-17-2021, 10:23 AM

Quote:

Originally Posted by 0XBF

I think I've found the simplest way to configure pipewire for a user in Slackware. Note that pipewire is only meant to be run on a per user basis, there is no equivalent to a "system daemon", like was available for pulseaudio.

In my $HOME/.profile script, I have the following lines to start pipewire and friends:

Code:

# ~/.profile
# Start pipewire daemons and bind them to the elogind session:
/usr/bin/daemon --bind --pidfiles=$HOME/.pidfiles --name=pipewire --command=/usr/bin/pipewire
/usr/bin/daemon --bind --pidfiles=$HOME/.pidfiles --name=pipewire-media-session --command=/usr/bin/pipewire-media-session
/usr/bin/daemon --bind --pidfiles=$HOME/.pidfiles --name=pipewire-pulse --command=/usr/bin/pipewire-pulse

Some notes:
I'm using daemon, since Slackware includes it. The '--bind' option will cause pipewire to exit with the last logout so it cleans itself up (using elogind in the backend). The '--name' option tells daemon to use a lock file so daemon only starts one instance. I didn't bother with a '--respawn', but you could use it if you want automatic respawns if a daemon crashes.

Then in my $HOME/.bash_profile script I source the .profle script with the following:

Code:

# ~/.bash_profile: executed by bash(1) for login shells.

if [ -f $HOME/.profile ]; then
  source $HOME/.profile
fi

The reasoning for this setup is that .bash_profile gets sourced as soon as you login at a tty console, and it gets sourced when you login using 'sddm'. The 'xdm' display manager on the other hand skips sourcing .bash_profile, but will still source .profile, which is why I have the daemon's starting in .profile. The end result is that pipewire gets started at any login; a display manager or from the console.

This also has the benefit that you don't have to touch any of pulseaudio's config files to use pipewire. I.e. No need to disable autospawning of pulseaudio or messing with xdg autostart files. Pipewire will always start right after login, and always before pulseaudio. If you want to switch back to pulseaudio then you just remove or comment out the relevent lines in .profile and pulseaudio will take over again (you will have to logout/login). I've tested this for all WM's and DE's included in slackware, using startx/startkwayland/sddm/xdm and pipewire is used everywhere with this setup.

That's all.

Nice work! Congratulations!

However, I do not think that the proper place of starting the PipeWire daemons is ~/.profile if we play the card of starting them on console login. Because probably some users will lament the slowdown on login - it happened in the past already, so I will not wonder if they will protest regarding a few seconds delay.

So, I believe that the proper place of starting them is ~/.xprofile

BUT, there's still a caveat: while this is a standard file for which looks the X11 sessions, we should tune further the Wayland infrastructure to recognize it.

Long story short, for example on /usr/share/sddm/scripts/Xsession we have

Code:

[ -f /etc/xprofile ] && . /etc/xprofile
[ -f /usr/local/etc/xprofile ] && . /usr/local/etc/xprofile
[ -f $HOME/.xprofile ] && . $HOME/.xprofile

That means that we have a convenient place to put code which is executed only when a graphical session is started.

But this code snipped lacks from /usr/share/sddm/scripts/wayland-session or /usr/bin/startkwayland, so the file will be ignored when starting a Wayland/Plasma5 session.

The solution is to add this code snippet to those two files and we will have an universal place to start the PipeWire daemons.

Regarding the --respawn option, even on the XDG files are used mainly because the daemons are started out of order and the startup will fail several times, please note that's very useful for restarting the PipeWire daemons - for debugging purpose of configs, for example. And this restarting of a daemon service is available only when it's used --respawn.

That's WHY, I for one, I strongly recommend the usage of it.

0XBF · 10-17-2021, 10:47 AM

Quote:

Originally Posted by LuckyCyborg

However, I do not think that the proper place of starting the PipeWire daemons is ~/.profile if we play the card of starting them on console login. Because probably some users will lament the slowdown on login. It happened in the past already, so I will not wonder if they will protest regarding a few seconds delay.

I haven't seen any slowdown on login using this setup, but the two machines I tested this on are only up to 5 years old. I'll try this setup on my Eee 1000H after I update it and see if its any different there.

Quote:

So, I believe that the proper place of starting them is ~/.xprofile

BUT, there's still a caveat: while this is a standard file for which looks the X11 sessions, we should tune further the Wayland infrastructure to recognize it.

I thought abut using .xprofile but like you stated, its not sourced universally, and would require editing default slackware provided files to make work. I used .profile and .bash_profile because both the wayland and X11 sddm/xdm scripts source it, and I want to have pipewire working at the console too (e.g. for when I'm running mocp without an X or wayland session).

Thanks for the feedback though. I've been using this to run pipewire without problems so I wanted to see if anyone here saw issues with it.

Quote:

Regarding the --respawn option, even on the XDG files are used mainly because the daemons are started out of order and the startup will fail several times, please note that's very useful for restarting the PipeWire daemons - for debugging purpose of configs, for example. And this restarting of a daemon service is available only when it's used --respawn.
That's WHY, I for one, I strongly recommend the usage of it.

Using '--respawn' could be a good idea and I noted that it can be used with daemon. When the pipewire daemons are started in order like in that .profile script I posted, everything seems to start up properly. I wasnt using the respawn feature so it would be more obvious if pipewire would have failed and exited when checking 'ps'. Another thought: Perhaps the slowdown you see when starting pipewire is due to the daemon spamming respawn attempts. Like I said, I have seen no slowdowns with the scripted .profile startup.

I'll also note that the only time I've seen pipewire legit crash (other than incorrect startup usage), is when pushing the buffer size to the limits when using pipewire built with jack. The pipewire-pulse replacement server itself seems pretty stable from my daily usage.

LuckyCyborg · 10-17-2021, 10:58 AM

Quote:

Originally Posted by 0XBF

I haven't seen any slowdown on login using this setup, but the two machines I tested this on are only up to 5 years old. I'll try this setup on my Eee 1000H after I update it and see if its any different there.

Believe me, you or me, we cannot test all hardware combinations and setups possible.

So, I bet that someone someday will lament about slowdowns by starting 3 commands on ~/.profile

Quote:

Originally Posted by 0XBF

I thought abut using .xprofile but like you stated, its not sourced universally, and would require editing default slackware provided files to make work. I used .profile and .bash_profile because both the wayland and X11 sddm/xdm scripts source it, and I want to have pipewire working at the console too (e.g. for when I'm running mocp without an X or wayland session).

I have just proposed for patching the -current for adding this support for xprofile files sourcing on Wayland sessions.

Let's hope this will adopted, after all, are minor changes which I believe that are generally useful.

https://www.linuxquestions.org/quest...ml#post6292958

BUT, for running the daemons for pure console... Yeah! You are right about using ~/.profile

Quote:

Originally Posted by 0XBF

Using '--respawn' could be a good idea and I noted that it can be used with daemon. When the pipewire daemons are started in order like in that .profile script I posted, everything seems to start up properly. I wasnt using the respawn feature so it would be more obvious if pipewire would have failed and exited when checking 'ps'. Another thought: Perhaps the slowdown you see when starting pipewire is due to the daemon spamming respawn attempts. Like I said, I have seen no slowdowns with the scripted .profile startup.

I'll also note that the only time I've seen pipewire legit crash (other than incorrect startup usage), is when pushing the buffer size to the limits when using pipewire built with jack. The pipewire-pulse replacement server itself seems pretty stable from my daily usage.

For example, anytime you make a configs change on PipeWire setup, you need to restart the daemons.

I believe that is nicer to issue a daemon restart command for "pipewire" - as it's enough, compared with the full desktop restart, by at least a full logout.

And after all is about a single "r" character on the command line.

As you already know, your first command could be this way:

Code:

/usr/bin/daemon -rB --pidfiles=$HOME/.run --name=pipewire /usr/bin/pipewire

Shorter, right?

And with client respawn, then also permitting commands like:

Code:

/usr/bin/daemon --pidfiles=$HOME/.run --name=pipewire --restart

The thing is that when you execute this command, the other 2 daemons falls too.

BUT, with the --respawn option, they will be automatically (re)started again.

Pithium · 10-17-2021, 11:19 AM

running the pipewire daemons from .profile could significantly impact startup since it's a blocking process. You can try to alleviate this but ending each line with & but that can result in race conditions when something doesn't launch properly.

I took the pulseaudio approach and it seems to be working fine. I created a .desktop launcher in ~/.config/autostart and removed all the launcher files for pulseaudio. This way pipewire starts at the same time and same way as the daemon it replaced.

LuckyCyborg · 10-17-2021, 11:26 AM

Quote:

Originally Posted by Pithium

running the pipewire daemons from .profile could significantly impact startup since it's a blocking process. You can try to alleviate this but ending each line with & but that can result in race conditions when something doesn't launch properly.

I took the pulseaudio approach and it seems to be working fine. I created a .desktop launcher in ~/.config/autostart and removed all the launcher files for pulseaudio. This way pipewire starts at the same time and same way as the daemon it replaced.

No need for & when it's used the daemon supervisor.

Because it's, well... a daemon supervisor which sinks itself on background, becoming a daemon, and drags with its client program.

Also, it could avoid the race conditions when it's instructed to start a unique instance of its client program - just like we do.

0XBF · 10-17-2021, 11:36 AM

Quote:

Originally Posted by Pithium

running the pipewire daemons from .profile could significantly impact startup since it's a blocking process. You can try to alleviate this but ending each line with & but that can result in race conditions when something doesn't launch properly.

My original method was a separate bash script in the style of an rc.d script that could be called with stop/start/restart arguments. I moved to inside .profile to make the setup more minimal. However, a separate script could still be called from .profile and backgrounded with the '&'. Then that script is free to complete startup of pipewire on its own in proper order, and .profile can continue on with execution. That might open up a race with pulseaudio... I haven't tested with backgrounding from the .profile script since there is no noticeable delay for starting pipewire the way I'm using here.

Thanks for the input.

Pithium · 10-17-2021, 01:43 PM

I've just become wary of using the .profile scripts for certain programs simply due to the way they handle lock files. While fiddling with both pulse and pipewire I've run into situations where the daemon restarts but doesn't clean up the lock files, resulting in some apps playing sound and others not. So now I'm super paranoid about how it starts and stops.

In general the pipewire backend seems much more predictable for my use case so I'm happy with it.

0XBF · 10-17-2021, 11:25 PM

Quote:

Originally Posted by 0XBF

I haven't seen any slowdown on login using this setup, but the two machines I tested this on are only up to 5 years old. I'll try this setup on my Eee 1000H after I update it and see if its any different there.

After 12 hours of updating, the 1000H is finally synced to the latest slackware-current. I set up my user to use pipewire with that .profile script and all is working fine. No noticeable slowdown at console login compared to not having anything in .profile. I also didn't notice a difference with or without '--respawn'. This is on a single core intel atom 1.6GHz, with 1GB of RAM, which most systems would easily beat.

I'll keep testing with this setup to see if it breaks. So far the only issue I've come across is having to remove a leftover /etc/pipewire/pipewire.conf file from an older pipewire version. The pipewire.conf file has changed many times over the last year and old versions are incompatible and prevent pipewire-media-session from starting. After cleaning it out pipewire works fine.

brobr · 10-27-2021, 11:52 AM

Hi, when trying out some audio programs with pipewire and jack installed (not the pipewire-jack module as I couldn't get it to replace jack completely), I run into some SBo programs not working, ones based around midi/fluidsynth:

With pipewire, fluidsynth, and therefore qsynth, cannot connect to jack, it seems to look for pulseaudio:

Quote:

17:41:03.865 Qsynth1: Failed to create the audio driver (alsa). Cannot continue without it.
fluidsynth: error: Unknown string setting 'audio.jack.id'
fluidsynth: error: Unknown integer parameter 'audio.jack.autoconnect'
fluidsynth: error: Unknown integer parameter 'audio.jack.multi'
fluidsynth: error: Unknown integer parameter 'synth.dump'
fluidsynth: warning: Requested 2 periods, got 3 instead
ALSA lib pcm_pulse.c:758

pulse_prepare) PulseAudio: Unable to create stream: Input/Output error

fluidsynth: warning: Audio device hardware configuration failed

Also things as drumstick, vmpk did not give any luck. Does anyone has a more positive experience?

(I got other midi things working ok with jack: amsynth, hydrogen ...)

---
EDIT: pipewire-jack becomes part of pipewire: https://gitlab.freedesktop.org/pipewire/pipewire

0XBF · 10-27-2021, 09:02 PM

Quote:

Originally Posted by brobr

Hi, when trying out some audio programs with pipewire and jack installed (not the pipewire-jack module as I couldn't get it to replace jack completely)

The version of pipewire that comes with Slackware isn't built against jack so this functionality doesn't work on a vanilla install. Once you have jack installed you can rebuild pipewire using the pipewire.SlackBuild that comes with current. You would have to edit it to change one or both of the following to true:

Code:

-Djack=enabled
-Dpipewire-jack=enabled

pipewire-jack=true builds the pw-jack wrapper tool to launch jack programs with.

jack=true builds the libraries to do the full system replacement.

If going for the full replacement, you have to also make the following links after rebuilding pipewire (e.g. in /usr/lib64):

Code:

cd /usr/lib64
ln -sf pipewire-0.3/jack/libjack.so.0 libjack.so.0.999.0
ln -sf pipewire-0.3/jack/libjacknet.so.0 libjacknet.so.0.999.0
ln -sf pipewire-0.3/jack/libjackserver.so.0 libjackserver.so.0.999.0

Then any jack aware program will see the running pipewire server as the jack server. You'll still need qjackctl or something to manage connections.

EDIT: There is a simpler way to link the pipewire-jack shared libraries, which I posted later in this thread here:
https://www.linuxquestions.org/quest...ml#post6297256

Quote:

Originally Posted by brobr

I run into some SBo programs not working, ones based around midi/fluidsynth:

With pipewire, fluidsynth, and therefore qsynth, cannot connect to jack, it seems to look for pulseaudio:

Code:

17:41:03.865 Qsynth1: Failed to create the audio driver (alsa). Cannot continue without it.
fluidsynth: error: Unknown string setting 'audio.jack.id'
fluidsynth: error: Unknown integer parameter 'audio.jack.autoconnect'
fluidsynth: error: Unknown integer parameter 'audio.jack.multi'
fluidsynth: error: Unknown integer parameter 'synth.dump'
fluidsynth: warning: Requested 2 periods, got 3 instead
ALSA lib pcm_pulse.c:758:(pulse_prepare) PulseAudio: Unable to create stream: Input/Output error

fluidsynth: warning: Audio device hardware configuration failed

Also things as drumstick, vmpk did not give any luck. Does anyone has a more positive experience?

(I got other midi things working ok with jack: amsynth, hydrogen ...)

I don't use fluidsynth/qsynth much so I tried to run it and I see the same error. With or without pipewire so this is a fluidsynth issue. I looked through fluidsynth source files and it looks like it will automatically detect and build against jack when compiling. I'm guessing this change was introduced at some point this year when slackware jumped to the fluidsynth 2.x series because I have used fluidsynth/qsynth in previous years without issue. I grabbed the slackbuild for fluidsynth and rebuilt it and fluidsynth/qsynth are working again. Also noticed this in the build log:

Code:

-- Checking for module 'jack'
--   Found jack, version 1.9.19

So I guess thats how it is with fluidsynth now.

I also dont use vmpk or drumstick much since I have a midi keyboard but both open and seem to run okay here.

brobr · 10-28-2021, 05:03 AM

Quote:

Originally Posted by 0XBF

The version of pipewire that comes with Slackware isn't built against jack so this functionality doesn't work on a vanilla install. Once you have jack installed you can rebuild pipewire using the pipewire.SlackBuild that comes with current. ..
..

Thanks a lot for this. I am going to try it out; makes a lot of sense (jack on SBo and pipewire in current, makes the latter miss the former at build-time).

After rebuilding pipewire against jack, and going the full monty, is it best to then remove jack? The pipewire-github mentions exporting an

Quote:

PIPEWIRE_LATENCY environment variable like so:

PIPEWIRE_LATENCY=128/48000 jack_simple_client

Could that be set in general (via a profile.d script or so)??

LuckyCyborg · 10-28-2021, 05:32 AM

Quote:

Originally Posted by brobr

Thanks a lot for this. I am going to try it out; makes a lot of sense (jack on SBo and pipewire in current, makes the latter miss the former at build-time).

After rebuilding pipewire against jack, and going the full monty, is it best to then remove jack? The pipewire-github mentions exporting an
Could that be set in general (via a profile.d script or so)??

The big trick with PipeWire is that the user should NOT remove either the PulseAudio or JACK.

Their infrastructure is still needed, because the PipeWire daemons replaces ONLY the audio servers at runtime.

brobr · 10-28-2021, 05:50 AM

repeat of next post, excuses

brobr · 10-28-2021, 05:52 AM

Quote:

Originally Posted by LuckyCyborg

The big trick with PipeWire is that the user should NOT remove either the PulseAudio or JACK.

Their infrastructure is still needed, because the PipeWire daemons replaces ONLY the audio servers at runtime.

Ok, thanks for that advice; so they're there for pipewire to feed/redirect all apps depending on jack or pulseaudio?

LuckyCyborg · 10-28-2021, 06:18 AM

Quote:

Originally Posted by brobr

Ok, thanks for that advice; so they're there for pipewire to feed/redirect all apps depending on jack or pulseaudio?

The applications uses the PulseAudio or JACK libraries and infrastructure to talk to what they believe to be the respective audio servers - in fact responds the PipeWire daemons.

The funny thing is that that the PipeWire design permits one application to talk JACK language, while another one to talk PulseAudio. While meanwhile another one talks directly Pipewireish. All of this happening simultaneous.