Using Pipewire instead of Pulseaudio in Slackware 15

brobr · 10-28-2021, 09:10 AM

Quote:

Originally Posted by 0XBF

..SlackBuild that comes with current. You would have to edit it to change one or both of the following to true:

Code:

-Djack=true
-Dpipewire-jack=true

Ok, 1st step done; Note that the 'true' should be 'enabled' for pipewire to compile.

Before, when say QMPlay2 (or a youtube video in the browser) occupied the soundcard, jack could not start. After recompiling qjackctl (against the pipewire/jack install) this crippling either/or setup is gone! Jack can work alongside other programs now (VLC is set to use jack for audio output). (Thanks pipewire!)

pw-top:

Quote:

S ID QUANT RATE WAIT BUSY W/Q B/Q ERR NAME

! 28 0 0 0.0µs 0.0µs 0.00 0.00 0 Dummy-Driver
! 29 0 0 0.0µs 0.0µs 0.00 0.00 0 Freewheel-Driver
! 37 0 0 0.0µs 0.0µs 0.00 0.00 0 Midi-Bridge
! 42 0 0 0.0µs 0.0µs 0.00 0.00 0 v4l2_input.pci-0000_00
44 1024 48000 109.5µs 19.0µs 0.01 0.00 0 alsa_output.pci-0000_0
51 1024 48000 87.0µs 14.1µs 0.00 0.00 0 + QMPlay2
58 0 0 33.1µs 0.4µs 0.00 0.00 0 + qjackctl
61 0 0 10.6µs 43.6µs 0.00 0.00 0 + vlc_21781

now getting the other stuff linked up...

Jan K. · 10-28-2021, 10:24 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.

Does it make sense to request pipewire being built with jack support in -current?

Or are there drawbacks, if jack is not used?

brobr · 10-28-2021, 02:06 PM

Well, it's confusing. Where I had before a setup with hydrogen that gave me output now there is nothing or a kind of short-circuit: no beats/drum sounds just ongoing -uncontrollable noise. Have to kill the program.
https://github.com/hydrogen-music/hydrogen/issues/1330

EDIT: By compiling the latest master from https://github.com/PipeWire/pipewire hydrogen worked again ;-)

0XBF · 10-28-2021, 05:47 PM

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

Code:

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)??

I haven't tried removing jack after switching to pipewire built with jack support. Same thing with pulseaudio. I'm not sure what builds against those packages and I like to have them around as fallback anyway.

I've been using the pipewire.conf file to set the latency when using pipewire. I just copied the file from /usr/share/pipewire/pipewire.conf and tweaked the settings there. the .conf file explains how to set it up for a single user or system wide. It does say those environment variables work in the pipewire git wiki but I haven't tried that method.

Quote:

Originally Posted by Jan K.

Does it make sense to request pipewire being built with jack support in -current?

Or are there drawbacks, if jack is not used?

We would need jack added to slackware, then pipewire could be enabled to build against it. Neither jack or pipewire-jack would be used by default, until configured. However, I've seen jack requested to be added before but its still not included. I guess its more of a niche user base that would use it so they leave it for third party repos to supply. I use jack so I would like if it was added officially and things were enabled to build against it (e.g. pipewire and fluidsynth).

Also, about pipewire: I think it works fine as a "pulseaudio replacement", but I've found it to be a little more unstable and more 'xruns' at low latency buffer sizes. After a few crashes in the middle of recording I switched back to jack. That was a few versions back so I've been meaning to try out the latest version with jack support again. I've just been using pipewire for day to day audio purposes otherwise. I do like what it offers though; having all audio and midi devices routable in the graph without having to mess with alsa/jack/midi/pulseaudio bridges is nice.

0XBF · 10-31-2021, 08:11 AM

In effort to keep up to date information in this thread...

Quote:

Originally Posted by 0XBF

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.

After reading a little further on the pipewire wiki, the simpler way to achieve full jack support is to use the /etc/ld.so.conf.d/ directory, making a file:

Code:

/etc/ld.so.conf.d/pipewire-jack-x86_64.conf

With the following line in it:

Code:

/usr/lib64/pipewire-0.3/jack/

Then either run ldconfig (as root), or reboot, which will cause ldconfig to pickup the new config file. Reference here: https://gitlab.freedesktop.org/pipew...K#installation

The original method I posted with the symlinks was from last year, before the wiki contained this info. A reference to that is here: https://gitlab.freedesktop.org/pipew.../snippets/1165

For the record I see that Arch linux is using the /etc/ld.so.conf.d method with their 'pipewire-jack-dropin' package here: https://aur.archlinux.org/packages/p...e-jack-dropin/

0XBF · 10-31-2021, 10:06 AM

I wrote a little script called 'pipewirerc' to start/stop/restart pipewire, using the daemon program. The idea was to clean up usage. The script is simple so I'll post it here (it is also attached).

Code:

#!/bin/sh

# pipewirerc - An rc style script for 
# managing pipewire with daemon.
#
# Call this script to start/stop pipewire.

piddir="$HOME/.pidfiles" 
daemon_path="/usr/bin/daemon"

if [ ! -x "$daemon_path" ]; then
  echo "daemon is not installed, exiting."
  exit 1
fi

start_pipewire() {
  $daemon_path -B --pidfiles=$piddir --name=pipewire /usr/bin/pipewire
  $daemon_path -B --pidfiles=$piddir --name=pipewire-media-session /usr/bin/pipewire-media-session

  # Kill pulseaudio to allow pipewire-pulse to take over an existing pulseaudio server:
  [ ! -e "$piddir/pipewire-pulse.pid" ] && pulseaudio -k 2> /dev/null
  $daemon_path -B --pidfiles=$piddir --name=pipewire-pulse /usr/bin/pipewire-pulse
}

stop_pipewire() {
  $daemon_path --pidfiles=$piddir --name=pipewire --stop
  $daemon_path --pidfiles=$piddir --name=pipewire-media-session --stop
  $daemon_path --pidfiles=$piddir --name=pipewire-pulse --stop
}

case "$1" in
  start)
    start_pipewire
    ;;
  stop)
    stop_pipewire
    ;;
  restart)
    stop_pipewire
    start_pipewire
    ;;
  *)
    echo "Usage: $0 start|stop|restart"
esac

The idea is to copy that script somewhere convenient in your home directory, then call it with start/stop/restart as needed.

On a stock slackware install (i.e. no mucking about with pulseaudio configs to disable autospawning) this will:

start - Start pipewire, pipewire-media-session, and pipewire-pulse, taking over from an existing pulseaudio session if one is running.

stop - Stops the above daemons, which reverts back to pulseaudio if pulseaudio's default configuration is still present.

restart - Just in case you need it, runs stop and then start.

With this you can test pipewire manually if you want just by calling './pipewirerc start' anytime during a session. Alternatively you can autostart it with whatever login autostart method you prefer. Personally I call it from my $HOME/.profile script so its used at all login types.

LuckyCyborg · 10-31-2021, 11:25 AM

Quote:

Originally Posted by 0XBF

I wrote a little script called 'pipewirerc' to start/stop/restart pipewire, using the daemon program. The idea was to clean up usage. The script is simple so I'll post it here (it is also attached).

Code:

#!/bin/sh

# pipewirerc - An rc style script for 
# managing pipewire with daemon.
#
# Call this script to start/stop pipewire.

piddir="~/.pidfiles" 
daemon_path="/usr/bin/daemon"

if [ ! -x "$daemon_path" ]; then
  echo "daemon is not installed, exiting."
  exit 1
fi

start_pipewire() {
  $daemon_path -B --pidfiles=$piddir --name=pipewire /usr/bin/pipewire
  $daemon_path -B --pidfiles=$piddir --name=pipewire-media-session /usr/bin/pipewire-media-session

  # Kill pulseaudio to allow pipewire-pulse to take over an existing pulseaudio server:
  pulseaudio -k 2> /dev/null
  $daemon_path -B --pidfiles=$piddir --name=pipewire-pulse /usr/bin/pipewire-pulse
}

stop_pipewire() {
  $daemon_path --pidfiles=$piddir --name=pipewire --stop
  $daemon_path --pidfiles=$piddir --name=pipewire-media-session --stop
  $daemon_path --pidfiles=$piddir --name=pipewire-pulse --stop
}

case "$1" in
  start)
    start_pipewire
    ;;
  stop)
    stop_pipewire
    ;;
  restart)
    stop_pipewire
    start_pipewire
    ;;
  *)
    echo "Usage: $0 start|stop|restart"
esac

The idea is to copy that script somewhere convenient in your home directory, then call it with start/stop/restart as needed.

On a stock slackware install (i.e. no mucking about with pulseaudio configs to disable autospawning) this will:

start - Start pipewire, pipewire-media-session, and pipewire-pulse, taking over from an existing pulseaudio session if one is running.

stop - Stops the above daemons, which reverts back to pulseaudio if pulseaudio's default configuration is still present.

restart - Just in case you need it, runs stop and then start.

With this you can test pipewire manually if you want just by calling './pipewirerc start' anytime during a session. Alternatively you can autostart it with whatever login autostart method you prefer. Personally I call it from my $HOME/.profile script so its used at all login types.

Nice script, BUT again I see that you ran away of --respawn option of the daemon supervisor...

Why this? You have some advantage(s) by NOT using it?

Using the --respawn, there's even available also the --restart option, like this:

Code:

       --restart
           Instruct a named daemon to terminate and restart its client process, by sending it a SIGUSR1 signal. This will cause the named daemon to send its client process a
           SIGTERM signal to stop it. If the named daemon had been started with the --restart option, the named daemon will then restart its client process. Otherwise, this
           has the same effect as the --stop option, and the named daemon's client process is not restarted.

           This option can only be used with the --name option. Note that the --chroot, --user, --name, --pidfiles and --pidfile (and possibly --config) options must be the
           same as for the target daemon.

BTW, and there I found a typo on the man page, as should be: "If the named daemon had been started with the --respawn option, the ..." because this way the daemon behaves.

0XBF · 10-31-2021, 11:37 AM

Quote:

Originally Posted by LuckyCyborg

Nice script, BUT again I see that you ran away of --respawn option of the daemon supervisor...

Why this? You have some advantage(s) by NOT using it?

Using the --respawn, there's even available also the --restart option, like this:

Code:

       --restart
           Instruct a named daemon to terminate and restart its client process, by sending it a SIGUSR1 signal. This will cause the named daemon to send its client process a
           SIGTERM signal to stop it. If the named daemon had been started with the --restart option, the named daemon will then restart its client process. Otherwise, this
           has the same effect as the --stop option, and the named daemon's client process is not restarted.

           This option can only be used with the --name option. Note that the --chroot, --user, --name, --pidfiles and --pidfile (and possibly --config) options must be the
           same as for the target daemon.

It's just my personal preference to not use the automatic respawning feature. I have found no difference in operation, with or without using it so I just left the command line options to their simplest implementation with named daemons.

Having the pipewirerc script start the three daemons in proper order negates the need for starting them all at the same time and spamming respawn until the daemons are all satisfied. If you want to try the script and add --respawn, its a simple addition to make.

On the --restart option: I find it doesn't work reliably, because the daemons dont restart automatically in the correct order, even when scripted in order. If pipewire-pulse is started before the pipewire-media-session it will fail. It was simpler to just stop and start the daemons in proper order as I showed there. Perhaps "--restart" option works better in conjunction with "--respawn", since it will continually try to start the daemons until satisfied. Feel free to add it if you want, but the script runs fine as written.

Edit: I see you found that --restart works with --respawn in the man page. Nice to have the option documented here in case someone wants to add the autorespawing option.

Further Edit: Also if one were wanting to leave pulseaudio available to use without modifying configs (as I do), I think the --restart operation has a built in delay which will allow pulseaudio to start if initiated during a desktop session (i.e. in plasma). By using stop+start, pulseaudio is handled with the '-k' option. In other words, using --restart will break the pipewire startup, cause pulseaudio will sneak in there before its delay is up.

brobr · 10-31-2021, 02:48 PM

Quote:

Originally Posted by 0XBF

After reading a little further on the pipewire wiki, the simpler way to achieve full jack support is to use the /etc/ld.so.conf.d/ directory, making a file:

Code:

/etc/ld.so.conf.d/pipewire-jack-x86_64.conf

With the following line in it:

Code:

/usr/lib64/pipewire-0.3/jack/

Then either run ldconfig (as root), or reboot

Ok I tried this with `pipewire built against jack` and this forced me to be more consistent with this set-up.

moc had to be rebuilt as well (against jack, pipewire-jack) in order not to crash aqualung.

Before the ld-config setup (i.e. with the linking) this crashing could be bypassed with `mocp -R jack` despite the error that jack was not found (as mentioned in this post: https://www.linuxquestions.org/quest...ml#post6297152).

With the ld-config this 'bypass' was no longer working (maybe by lack of the links??) and `moc -R jack` was dead.

Recompiling moc against jack/pipewire-jack solved this.

moc via alsa still crashes aqualung, but via jack works flawlessly now (to evade this I put an `alias mocp='mocp -R jack'` in ~/.bash_aliases). With a great sound, can play two albums at the same time now plus watrching a video with sound (Of course this is funny crazy ;-)

EDIT:
Can not run qjackctl anymore (also after rebuilding)

Quote:

23:15:19.474 Statistics reset.
23:15:25.281 JACK is starting...
23:15:25.281 /usr/bin/jackd -dalsa -dhw:0
23:15:25.294 JACK was started with PID=23116.
23:15:25.299 JACK was stopped
23:15:27.321 Could not connect to JACK server as client. - Overall operation failed. - Unable to connect to server. Please check the messages window for more info.

not good

EDIT2:
bringing back the links solved this. The ldconfig doesn't cover it all

0XBF · 11-01-2021, 05:59 PM

I still have not tried installing aqualung yet so I can't suggest anything to try there. However, qjackctl should have no problem running if the switch to pipewire-jack was done correctly.

If pipewire's jack libraries are linked correctly, and the pipewire daemons are already running, then when you start up qjackctl it will show that a jack server is already running. You should be able to manage connections here. You cannot set the sample rate and buffer settings with qjackctl anymore, because that is now a pipewire.conf file setting. In other words, qjackctl should start and connect fine, just some jack specific things will not work, due to there actually being a pipewire server running, with its own config file setup.

If the pipewire jack libraries are not properly linked, then programs are not able to find and connect to the pipewire-jack server. E.g. When starting up qjackctl, it will not show a running jack server. Starting the jack server from qjackctl will just start a separate 'jackd' instance.

After linking pipewires jack libraries with the /etc/ld.so.conf.d/ method and running ldconfig, you should see pipewire's libraries linked when you print the dynamic linker's cache. Here's my system, using the same setup:

Code:

# /sbin/ldconfig -p | grep libjack
        libjackserver.so.0 (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjackserver.so.0
        libjackserver.so.0 (libc6,x86-64) => /usr/lib64/libjackserver.so.0
        libjackserver.so (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjackserver.so
        libjackserver.so (libc6,x86-64) => /usr/lib64/libjackserver.so
        libjacknet.so.0 (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjacknet.so.0
        libjacknet.so.0 (libc6,x86-64) => /usr/lib64/libjacknet.so.0
        libjacknet.so (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjacknet.so
        libjacknet.so (libc6,x86-64) => /usr/lib64/libjacknet.so
        libjack.so.0 (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjack.so.0
        libjack.so.0 (libc6,x86-64) => /usr/lib64/libjack.so.0
        libjack.so (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjack.so
        libjack.so (libc6,x86-64) => /usr/lib64/libjack.so

Regarding 'mocp': .
The usage 'mocp -R jack' does not work with the package that is supplied by slackware. This would be true if you used pipewire-jack, or regular 'jack'. Slackware doesn't provide jack in its official packages, so all build options to use jack are disabled. 'mocp' comes from current so it needs to be rebuilt after jack is installed. Then it automatically detects jack and builds in support to mocp. From mocp's build log on a system with jack:

Code:

moc-2.5.2/jack.c
moc-2.5.2/jack.h
checking for JACK... yes
checking for library containing jack_client_open... -ljack
Sound Drivers:     OSS ALSA JACK

This is a problem with running jack on Slackware in general. Any official packages have not been compiled with jack support, so programs like 'mocp' and 'fluidsynth' don't have jack support, typically only pulseaudio and/or alsa support is built in. The nice thing about pipewire is that it bridges these things for you. The stock package for 'mocp' should still start fine with alsa or pulseaudio, and that can be routed in 'qjackctl' or 'catia' into 'pipewire-jack' connections, etc.

marav · 11-02-2021, 11:09 AM

Fedora 35 replaced Pipewire Media Session with Wireplumber

I used the 0.4.4 release
https://gitlab.freedesktop.org/pipew...r/-/tree/0.4.4

Compiled with

Code:

$ meson setup -Dsystemd=disabled -Dsystemd-user-service=false --prefix=/usr build
$ meson compile -C build
$ ninja -C build install

Added a /etc/xdg/autostart/wireplumber.desktop ( and, e.g. pipewire-media-session.desktop.old )

Code:

[Desktop Entry]
Version=1.0
Name=Wireplumber
Comment=Start Wireplumber
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=wireplumber /usr/bin/wireplumber
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1

works fine here

Code:

marav     5375  0.0  0.0   4072  2640 ?        S    16:27   0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
marav     5378  0.4  0.1 139048 27576 ?        Sl   16:27   0:12  \_ pipewire: /usr/bin/pipewire
marav     5379  0.0  0.0   4072  2636 ?        S    16:27   0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
marav     5384  0.5  0.4 102464 69668 ?        SLl  16:27   0:15  \_ pipewire-pulse: /usr/bin/pipewire-pulse
marav     5387  0.0  0.0   4072  2612 ?        S    16:27   0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=wireplumber /usr/bin/wireplumber
marav     5390  0.4  0.1 332580 25216 ?        SLl  16:27   0:11  \_ wireplumber: /usr/bin/wireplumber

EDIT :

It's probably still a little early. So, it's just a POC
But as long as it's Redhat that maintains pipewire, it's probably something to consider

brobr · 11-02-2021, 02:33 PM

Quote:

Originally Posted by 0XBF

Code:

# /sbin/ldconfig -p | grep libjack
        libjackserver.so.0 (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjackserver.so.0
        libjackserver.so.0 (libc6,x86-64) => /usr/lib64/libjackserver.so.0
        
..

Regarding 'mocp': .

Yes, all present (but that is with the links made via SlackBuild/doinst.sh); and building mocp again against jack is understandable; that it did something (albeit with an error message) without being compiled against jack, was weird anyway (and produced gibberish if something else was playing). Now it's fine:

Quote:

bash-5.1$ mocp
Running the server...
Trying JACK...

0XBF · 11-02-2021, 04:48 PM

Quote:

Originally Posted by marav

Fedora 35 replaced Pipewire Media Session with Wireplumber

I used the 0.4.4 release
https://gitlab.freedesktop.org/pipew...r/-/tree/0.4.4

Compiled with

Code:

$ meson setup -Dsystemd=disabled -Dsystemd-user-service=false --prefix=/usr build
$ meson compile -C build
$ ninja -C build install

Added a /etc/xdg/autostart/wireplumber.desktop ( and, e.g. pipewire-media-session.desktop.old )

Code:

[Desktop Entry]
Version=1.0
Name=Wireplumber
Comment=Start Wireplumber
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=wireplumber /usr/bin/wireplumber
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1

works fine here

Code:

marav     5375  0.0  0.0   4072  2640 ?        S    16:27   0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
marav     5378  0.4  0.1 139048 27576 ?        Sl   16:27   0:12  \_ pipewire: /usr/bin/pipewire
marav     5379  0.0  0.0   4072  2636 ?        S    16:27   0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
marav     5384  0.5  0.4 102464 69668 ?        SLl  16:27   0:15  \_ pipewire-pulse: /usr/bin/pipewire-pulse
marav     5387  0.0  0.0   4072  2612 ?        S    16:27   0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=wireplumber /usr/bin/wireplumber
marav     5390  0.4  0.1 332580 25216 ?        SLl  16:27   0:11  \_ wireplumber: /usr/bin/wireplumber

EDIT :

It is probably still a little early. So, it's just a POC
But as long as it is Redhat that maintains pipewire, it is probably something to consider

Interesting. I've only played around with Fedora 34, which was using the pipewire-media-session daemon still.

Wireplumber being an api wrapper for pipewire, I wonder if they are planning on adding some sort of pipewire control application or gnome add-on? Currently controlling pipewire is done through qjackctl (or catia) for the jack backend, then pavucontrol for the pulseaudio backend. Then some features of pipewire can only be controlled through config or cli based tools. A more unified approach would be helpful.

marav · 11-02-2021, 05:13 PM

Quote:

Originally Posted by 0XBF

Interesting. I've only played around with Fedora 34, which was using the pipewire-media-session daemon still.

Wireplumber being an api wrapper for pipewire, I wonder if they are planning on adding some sort of pipewire control application or gnome add-on? Currently controlling pipewire is done through qjackctl (or catia) for the jack backend, then pavucontrol for the pulseaudio backend. Then some features of pipewire can only be controlled through config or cli based tools. A more unified approach would be helpful.

From what I understand, this is exactly the purpose
https://pipewire.pages.freedesktop.org/wireplumber/

marav · 11-03-2021, 12:09 PM

Interesting :

https://www.youtube.com/watch?v=NB1iodnqELY

for some people, no doubt