LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 04-20-2021, 08:15 AM   #1
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,257

Rep: Reputation: 228Reputation: 228Reputation: 228
Thumbs up Using Pipewire instead of Pulseaudio in Slackware 15


Now that Pat has included the daemon package for what will become Slackware 15, I'll note here what is needed in order to use Pipewire instead of Pulseaudio. The original post is here and was provided by ZhaoLin1457. I'm just putting the details of that post here for better visibility.

First, you will need add the following 3 desktop files in:
Code:
/etc/xdg/autostart
pipewire.desktop
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
pipewire-pulse.desktop
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Pulse
Comment=Start the PipeWire Pulse
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
pipewire-media-session.desktop
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media Session
Comment=Start the PipeWire Media Session
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
Then, you need to edit:
Code:
/etc/pulse/client.conf
and change:
Code:
autospawn = yes
to
Code:
autospawn = no
Remove, or place:
Code:
/etc/xdg/autostart/pulseaudio.desktop
in a backup directory somewhere else. Thanks to LuckyCyborg for this suggestion.

Log out and log back in. You should now see pipewire running:
Code:
ps -ef | grep pipewire
stormtracknole     1833     1  0 07:34 ?        00:00:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session
stormtracknole     1856     1  0 07:34 ?        00:00:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
stormtracknole     1865  1856  0 07:34 ?        00:00:07 pipewire-pulse: /usr/bin/pipewire-pulse
angel     1879     1  0 07:34 ?        00:00:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
stormtracknole     1881  1833  0 07:34 ?        00:00:00 pipewire-media-session: /usr/bin/pipewire-media-session
stormtracknole     1882  1879  0 07:34 ?        00:00:05 pipewire: /usr/bin/pipewire
stormtracknole     4442  4345  0 08:04 pts/3    00:00:00 grep --color pipewire
I modified LuckyCyborg's daemon SlackBuild to include these files along the changes needed for pulse.

SlackBuild:
Code:
#!/bin/bash

# Copyright 2005-2018  Patrick J. Volkerding, Sebeka, MN, USA
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

cd $(dirname $0) ; CWD=$(pwd)

PKGNAM=daemon
VERSION=${VERSION:-$(echo $PKGNAM-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
BUILD=${BUILD:-1}

NUMJOBS=${NUMJOBS:-" -j$(expr $(nproc) + 1) "}

# Automatically determine the architecture we're building on:
if [ -z "$ARCH" ]; then
  case "$(uname -m)" in
    i?86) ARCH=i586 ;;
    arm*) readelf /usr/bin/file -A | egrep -q "Tag_CPU.*[4,5]" && ARCH=arm || ARCH=armv7hl ;;
    # Unless $ARCH is already set, use uname -m for all other archs:
    *) ARCH=$(uname -m) ;;
  esac
  export ARCH
fi

# If the variable PRINT_PACKAGE_NAME is set, then this script will report what
# the name of the created package would be, and then exit. This information
# could be useful to other scripts.
if [ ! -z "${PRINT_PACKAGE_NAME}" ]; then
  echo "$PKGNAM-$VERSION-$ARCH-$BUILD.txz"
  exit 0
fi

TMP=${TMP:-/tmp}
PKG=$TMP/package-$PKGNAM

if [ "$ARCH" = "i386" ]; then
  SLKCFLAGS="-O2 -march=i386 -mcpu=i686"
elif [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "i586" ]; then
  SLKCFLAGS="-O2 -march=i586 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686"
elif [ "$ARCH" = "s390" ]; then
  SLKCFLAGS="-O2"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
elif [ "$ARCH" = "armv7hl" ]; then
  SLKCFLAGS="-O3 -march=armv7-a -mfpu=vfpv3-d16"
else
  SLKCFLAGS="-O2"
fi

rm -rf $PKG
mkdir -p $TMP $PKG
cd $TMP
rm -rf $PKGNAM-$VERSION
tar xvf $CWD/$PKGNAM-$VERSION.tar.?z || exit 1
cd $PKGNAM-$VERSION || exit 1
chown -R root:root .
find . \
  \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \
  -exec chmod 755 {} \+ -o \
  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
  -exec chmod 644 {} \+

./configure \
  --prefix=/usr \
  --enable-logind

make $NUMJOBS CFLAGS="$SLKCFLAGS" || exit 1

make install DESTDIR=$PKG || exit 1
make install-daemon-conf DESTDIR=$PKG || exit 1
make install-daemon-html DESTDIR=$PKG DAEMON_HTMLDIR=/usr/doc/$PKGNAM-$VERSION || exit 1

mv $PKG/etc/daemon.conf $PKG/etc/daemon.conf.new

mkdir -p $PKG/etc/xdg/autostart
mkdir -p $PKG/etc/pulse
cp -a $CWD/pipewire-media-session.desktop $PKG/etc/xdg/autostart/pipewire-media-session.desktop.new
cp -a $CWD/pipewire-pulse.desktop $PKG/etc/xdg/autostart/pipewire-pulse.desktop.new
cp -a $CWD/pipewire.desktop $PKG/etc/xdg/autostart/pipewire.desktop.new
cp -a $CWD/client.conf $PKG/etc/pulse/client.conf.new

mkdir -p $PKG/usr/doc/$PKGNAM-$VERSION
cp -a \
  COPYING* INSTALL LICENSE README* REFERENCES \
  $PKG/usr/doc/$PKGNAM-$VERSION

# If there's a CHANGELOG, installing at least part of the recent history
# is useful, but don't let it get totally out of control:
if [ -r CHANGELOG ]; then
  DOCSDIR=$(echo $PKG/usr/doc/*-$VERSION)
  cat CHANGELOG | head -n 1000 > $DOCSDIR/CHANGELOG
  touch -r CHANGELOG $DOCSDIR/CHANGELOG
fi

mkdir -p $PKG/install
cat $CWD/doinst.sh > $PKG/install/doinst.sh
cat $CWD/slack-desc > $PKG/install/slack-desc

# Build the package:
cd $PKG
/sbin/makepkg -l y -c n $TMP/$PKGNAM-$VERSION-$ARCH-$BUILD.txz
doinst.sh
Code:
#!/bin/sh
config() {
  NEW="$1"
  OLD="`dirname $NEW`/`basename $NEW .new`"
  # If there's no config file by that name, mv it over:
  if [ ! -r $OLD ]; then
    mv $NEW $OLD
  elif [ "`cat $OLD | md5sum`" = "`cat $NEW | md5sum`" ]; then # toss the redundant copy
    rm $NEW
  fi
  # Otherwise, we leave the .new copy for the admin to consider...
}

config etc/daemon.conf.new
config etc/xdg/autostart/pipewire-media-session.desktop.new
config etc/xdg/autostart/pipewire-pulse.desktop.new
config etc/xdg/autostart/pipewire.desktop.new
config etc/pulse/client.conf.new
I can upload the full SlackBuild if anyone is interested. Just make sure that the desktop files and the client.conf file exist in the directory where your SBo file lies.

So far, I haven't ran into any issues. I haven't tested Bluetooth yet. Hopefully this tutorial will help you getting Pipewire going. Thanks to Pat for including this package; ZhaoLin1457 for his amazing work and LuckyCyborg for providing the SBo.

Last edited by stormtracknole; 04-20-2021 at 10:12 AM. Reason: Adding LuckyCyborg's suggestion
 
Old 04-20-2021, 08:20 AM   #2
tramtrist
Member
 
Registered: Jul 2018
Location: Cincinnati USA
Distribution: Slackware
Posts: 524

Rep: Reputation: 323Reputation: 323Reputation: 323Reputation: 323
This is awesome. Thank you!
 
1 members found this post helpful.
Old 04-20-2021, 08:29 AM   #3
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 2,785

Rep: Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526
@stormtracknole

You got right the PipeWire setup! Congratulations!

A similar setup I use myself since @raforg added the elogind integration on this daemon supervisor, after the feature request made by @ZhaoLin1457, and this setup works quite fine.

However, I for one I believe that those XDG autostart files should be placed on the PipeWire package.

Eventually, IF you prefer them on a custom made package, you may just put them on a pipewire-xdg-autostart package, for example. This way you do not need to modify any stock package from Slackware - at least, not for this.

BTW, you can use sed to patch on-fly the PulseAudio config file, instead of replacing it, via the doinst.sh of course.

BUT, I still hope that our BDFL will add those XDG autostart files (at least as examples) on the stock PipeWire package.

While as replacement of PulseAudio server is of course a very honorable purpose, it's still an optional/alternate solution, for Wayland/Plasma5 the PipeWire do many other things, then it's very important those daemons to be up and running, if we want a full functionality of that particular desktop environment.

PS. You put TWO of "of" on the thread tile.

Last edited by LuckyCyborg; 04-20-2021 at 08:50 AM.
 
4 members found this post helpful.
Old 04-20-2021, 08:50 AM   #4
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,257

Original Poster
Rep: Reputation: 228Reputation: 228Reputation: 228
Quote:
Originally Posted by LuckyCyborg View Post
@stormtracknole

You got right the PipeWire setup! Congratulations!

A similar setup I use myself since @raforg added the elogind integration on this daemon supervisor, after the feature request made by @ZhaoLin1457, and this setup works quite fine.

However, I for one I believe that those XDG autostart files should be placed on the PipeWire package.

Eventually, IF you prefer them on a custom made package, you may just put them on a pipewire-xdg-autostart package, for example. This way you do not need to modify any stock package from Slackware - at least, not from this.

BTW, you can use sed to patch on-fly the PulseAudio config file, instead of replacing it, via the doinst.sh of course.

BUT, I still hope that our BDFL will add those XDG autostart files (at least as examples) on the stock PipeWire package.

While as replacement of PulseAudio server is of course a very honorable purpose, it's still an optional/alternate solution, for Wayland/Plasma5 the PipeWire do many other things, then it's very important those daemons to be up and running, if we want a full functionality of that particular desktop environment.

PS. You put TWO of "of" on the thread tile.
Thanks!

I am curious how this can be handled for the folks that don't want to use Pipewire. Providing the desktop files might be helpful to have them at least staged, or even have a modified version of the daemon package in testing perhaps.

Arg, I just noticed my typo in the thread title. This is what I get for starting threads in the morning before having coffee. :/

Last edited by stormtracknole; 04-20-2021 at 08:52 AM.
 
Old 04-20-2021, 09:36 AM   #5
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 2,785

Rep: Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526
Quote:
Originally Posted by stormtracknole View Post
I am curious how this can be handled for the folks that don't want to use Pipewire.
Simply! Just like @ZhaoLin1457 proposed in the requests thread: putting them as "sample" files, which could be manually renamed by the users wanting to use them.

Quote:
Originally Posted by stormtracknole View Post
Providing the desktop files might be helpful to have them at least staged, or even have a modified version of the daemon package in testing perhaps.
What business have the daemon package with the PipeWire startup files?

For this daemon supervisor, the PipeWire daemons are just programs to supervise.

AND, WHAT IF we want the daemon to supervise even more programs? We should modify its package every time?

Again, probably the best idea is to create a noarch package containing those startup files, named for example: pipewire-xdg-autostart.

Speaking of switching the audio server to PipeWire and back to PulseAudio, probably the best idea is to have a script similar with the one used on SBo packages for the NVIDIA blobs: nvidia-switch

Let's say in our case to be named: audioserver-switch, which to change the configuration properly for a method or other.

BTW, you forgot something in your tutorial:

the file /etc/xdg/autostart/pulseaudio.desktop should be removed or renamed with a neutral extension.

Last edited by LuckyCyborg; 04-20-2021 at 09:42 AM.
 
1 members found this post helpful.
Old 04-20-2021, 09:46 AM   #6
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,257

Original Poster
Rep: Reputation: 228Reputation: 228Reputation: 228
Quote:
Originally Posted by LuckyCyborg View Post
Simply! Just like @ZhaoLin1457 proposed in the requests thread: putting them as "sample" files, which could be manually renamed by the users wanting to use them.



What business have the daemon package with the PipeWire startup files?

For this daemon supervisor, the PipeWire daemons are just programs to supervise.

AND, WHAT IF we want the daemon to supervise even more programs? We should modify its package every time?

Again, probably the best idea is to create a noarch package containing those startup files, named for example: pipewire-xdg-autostart.

Speaking of switching the audio server to PipeWire and back to PulseAudio, probably the best idea is to have a script similar with the one used on SBo packages for the NVIDIA blobs: nvidia-switch

Let's say in our case to be named: audioserver-switch, which to change the configuration properly for a method or other.

BTW, you forgot something in your tutorial:

the file /etc/xdg/autostart/pulseaudio.desktop should be removed or renamed with a neutral extension.
Good points. A noarch package would definitely work.

That is interesting about the pulseaudio.desktop file. I haven't renamed in my system. I would think that making the change in the client.conf would be enough, but maybe not? I haven't spotted any yet. Wouldn't editing the client.conf file do the exact same thing?
 
Old 04-20-2021, 09:51 AM   #7
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 2,785

Rep: Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526
Quote:
Originally Posted by stormtracknole View Post
Good points. A noarch package would definitely work.
Of course would work.

Quote:
Originally Posted by stormtracknole View Post
That is interesting about the pulseaudio.desktop file. I haven't renamed in my system. I would think that making the change in the client.conf would be enough, but maybe not? I haven't spotted any yet. Wouldn't editing the client.conf file do the exact same thing?
You should do both of those two changes. Be it the config file or the autostart file.

Technically, the pipewire-pulse daemon works properly because the pulse server looks being started later, and it finds the takeover, then bail out.

BUT, we cannot trust the order of starting those XDG files - there is no guarantee. Better to assume whatever order of startup.

Last edited by LuckyCyborg; 04-20-2021 at 10:09 AM.
 
2 members found this post helpful.
Old 04-20-2021, 10:13 AM   #8
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,257

Original Poster
Rep: Reputation: 228Reputation: 228Reputation: 228
Quote:
Originally Posted by LuckyCyborg View Post
Of course would work.



You should do both of those two changes. Be it the config file or the autostart file.

Technically, the pipewire-pulse daemon works properly because the pulse server looks being started later, and it finds the takeover, then bail out.

BUT, we cannot trust the order of starting those XDG files - there is no guarantee. Better to assume whatever order of startup.
Good points again! I added your suggestion to the main post. Thanks!!
 
Old 04-20-2021, 10:17 AM   #9
FTIO
Member
 
Registered: Mar 2015
Location: Las Vegas, NV
Distribution: Slackware 15.0, Slackware 14.2_x64, Slackware 14.1 x86
Posts: 553

Rep: Reputation: 324Reputation: 324Reputation: 324Reputation: 324
This is *NOT* a put down of the work that's gone into this Pipewire thing, just an observation from an ignorant user who doesn't program at all in any way.

If, as ZhaoLin1457, LuckyCyborg, et al, keep trying to say that adding/making this a daemon is 'so easy/simple', then why would it be so hard to just have the three audio things - ALSA, pulseaudio, Pipewire - as choices of which the user would like to use? I hate that pulseaudio tried to take over, like a bacterial disease of some kind, and now this Pipewire thing being kinda shoved down our throats by those of us with no voice in the matter, and when ALSA, left behind and thrown under the bus, 'just worked' (and personally feel works extremely well) and is no longer even mentioned.

Wouldn't "...putting them as "sample" files, which could be manually renamed by the users wanting to use them." - ALSA, pulseaudio or Pipewire - be a really Good Thing©®™?
 
1 members found this post helpful.
Old 04-20-2021, 10:37 AM   #10
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,257

Original Poster
Rep: Reputation: 228Reputation: 228Reputation: 228
Quote:
Originally Posted by FTIO View Post
This is *NOT* a put down of the work that's gone into this Pipewire thing, just an observation from an ignorant user who doesn't program at all in any way.

If, as ZhaoLin1457, LuckyCyborg, et al, keep trying to say that adding/making this a daemon is 'so easy/simple', then why would it be so hard to just have the three audio things - ALSA, pulseaudio, Pipewire - as choices of which the user would like to use? I hate that pulseaudio tried to take over, like a bacterial disease of some kind, and now this Pipewire thing being kinda shoved down our throats by those of us with no voice in the matter, and when ALSA, left behind and thrown under the bus, 'just worked' (and personally feel works extremely well) and is no longer even mentioned.

Wouldn't "...putting them as "sample" files, which could be manually renamed by the users wanting to use them." - ALSA, pulseaudio or Pipewire - be a really Good Thing©®™?
In my opinion, Slackware can do that right now. Pat provides an alsa only system. Pipewire will replace Pulse at some point, but these steps highlighted in this thread can help people use either or. You have brought up valid points. When it comes to software, things get left behind at one point or another. Either because the code can't be worked on anymore, or it is not compatible where the technology is moving to. I don't agree with it, but that's just the way things are. Pat has done a good job at keeping Slackware from transitioning too fast or into the latest and greatest (just because).

One of the many things that I love about Slackware is that it is a platform that can be very easily adjusted to your needs. It's just about impossible to have a Pulse free system in Fedora or Ubuntu.
 
1 members found this post helpful.
Old 04-20-2021, 10:50 AM   #11
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 2,785

Rep: Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526
Quote:
Originally Posted by FTIO View Post
This is *NOT* a put down of the work that's gone into this Pipewire thing, just an observation from an ignorant user who doesn't program at all in any way.

If, as ZhaoLin1457, LuckyCyborg, et al, keep trying to say that adding/making this a daemon is 'so easy/simple', then why would it be so hard to just have the three audio things - ALSA, pulseaudio, Pipewire - as choices of which the user would like to use? I hate that pulseaudio tried to take over, like a bacterial disease of some kind, and now this Pipewire thing being kinda shoved down our throats by those of us with no voice in the matter, and when ALSA, left behind and thrown under the bus, 'just worked' (and personally feel works extremely well) and is no longer even mentioned.

Wouldn't "...putting them as "sample" files, which could be manually renamed by the users wanting to use them." - ALSA, pulseaudio or Pipewire - be a really Good Thing©®™?
Look, the PipeWire is not shoved down on no one throat.

It's just an Audio/Video server well integrated in (and used by) my desktop of choice: Wayland/Plasma5

Yes, it has also audio support, and it's capable to replace the PulseAudio server, but also it gives the taskbar thumbnails - up to being behind things like remote desktop or screen recording/sharing on Wayland.

I for one I look to future and I believe that PulseAudio is already on verge to go on retirement.

For your information, the PipeWire is the PulseAudio successor. Realtime and now with Video.

I do not think is the place for us to discuss (yet again) about pure-ALSA. Because there we talk always about PulseAudio - present and future.

However, the pure-ALSA needs much more than those "sample" files from our "game" ...

It needs something which our BDFL tried to provide, while ending on throwing the towel on maintaining this thing: a huge set of dedicated packages for pure-ALSA. From what I understand, the required effort to maintain this, compared with the financial revenues of doing this, ends with a simple conclusion:

it's not financially worth to supporting pure-ALSA.

Last edited by LuckyCyborg; 04-20-2021 at 11:14 AM.
 
Old 04-20-2021, 10:52 AM   #12
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 2,785

Rep: Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526Reputation: 2526
Quote:
Originally Posted by stormtracknole View Post
Pat provides an alsa only system.
Provided! This was in the past.

Now we have PulseAudio and PipeWire as choices and I am quite happy.

Last edited by LuckyCyborg; 04-20-2021 at 11:03 AM.
 
3 members found this post helpful.
Old 04-20-2021, 11:07 AM   #13
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,257

Original Poster
Rep: Reputation: 228Reputation: 228Reputation: 228
Quote:
Originally Posted by LuckyCyborg View Post
Provided! This was in the past.

Now we have PulseAudio and PipeWire as choices and I am quite happy.
I'm pretty happy also with the choices.
 
Old 04-20-2021, 11:22 AM   #14
chemfire
Member
 
Registered: Sep 2012
Posts: 365

Rep: Reputation: Disabled
The reasons are pretty simple but it helps to understand the actual role of ALSA, which has not gone anywhere. ALSA isn't really an alternative to Pules/Pipewire. Maybe ALSA + jack and a few other things could be thought of that way. ALSA is a lower level interface than pulse/pipe wire. ALSA replaces OSS really. Pulse for example does not have drivers for your audio card - ALSA does.

ALSA as an interface works well enough for a simple case of basic PC audio needs where there is one card in the system or a least a fixed number of cards and the sync does not change much. There were/are various ALSA plugins like dmix, rateconvert, softvol etc that made it possible to have a pretty good audio experience if your needs were very conventional (like 1990s PC). It breaks down when you say want to use HDMI while docked on a laptop and the sound card and builtin speakers when on the move. Were there 'solutions' like kludgy udev scrips change the default card an HDMI display is detected etc, yes lots of people did stuff like that myself included. It was never very flexible though and beyond the capability of anyone not willing to at least do some serious shell scripting. Most applications could not deal with the changes live either and required a restart (of the app not the PC). This gets irritating pretty fast if you need to close your browser and all its tabs before you can join a online meeting. Pulse/Pipewire provides an abstraction for audio sources and syncs. So program playing audio via Pulse for example can just keep playing to Pulse even if the output changes underneath it. It also means stuff like downmix to stereo works and you can still hear all the audio channels on your laptop speakers if you have to disconnect from your receiver's HDMI to let you kids use the TV. Then there is the more fidly things - oh I want to make the output of application X louder without turning down all my other system sound.. If that app does not give you a volume control about the only thing you could do with ALSA is create another virtual PCM device for use with that specific app and put a softvol control on it, that is not very salable and not useful when you are in the middle of doing stuff. This type of functionality is really important to a lot of people.

Now Pulse is not without its problems and I am not advocating for it. It makes it hard to use a lot of the advanced stuff on fancy cards like hardware EQs, it adds latency that makes it unsuitable for a lot of audio editing/recording/musical work. I don't do those things so I don't have all the details. I believe those people though. Just like the ALSA is all you need crowd should believe some of us need an audio server/daemon even if they don't. I think its great that Pat provides builds of Slackware not linked to Pulse so that people who don't need an audio daemon can skip that or need to build something else up on top of ALSA can do so. They key thing to take away though is ALSA's job is really to expose audio devices to the system, its not really built to handle the application layers needs.

Now a bit of history, for some folks. Prior to ALSA there was OSS (Open Sound System) which had both proprietary and OSS (Open Source Software) implementations. OSS was like ALSA in most respects, really all that matter for this discussion, just accept it was even less flexible. Again it works for the 90s PC model of audio, where you have a couple source line-in/mic and one sync line out; and typical one application trying to do audio at a time. A lot of our applications were originally built with OSS support. They are internally plumbed for that model. Their OSS interfaces were forklifted out or made a compile switch and ALSA interfaces were bolted on. The SAME thing is done to support Pulse. Its not possible without patching many of these apps for them to support multiple audio driver interfaces. You have PICK ONE at build time. I don't see Pulse as trying to 'take over' not in the way system-d did/does. Its simple a matter of pulse kinda need to assume exclusive access to the ALSA interface to do what it does, and if Pat wants to ship a distro where most of the audio apps just behave themselves that means they have to use Pulse for now; just like if the world moves to Pipewire they will probably have to assume Pipewire or use some Pulse-to-Pipewire bridge just like we used to have to preload the AOSS library..
 
10 members found this post helpful.
Old 04-20-2021, 11:29 AM   #15
phenixia2003
Senior Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 1,052

Rep: Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006
Hello,

Quote:
Originally Posted by LuckyCyborg View Post
BTW, you forgot something in your tutorial:

the file /etc/xdg/autostart/pulseaudio.desktop should be removed or renamed with a neutral extension.
Another less intrusive solution is to copy /etc/xdg/autostart/pulseaudio.desktop in ~/.config/autostart, and add the following line in the copy :

Code:
Hidden=true
--
SeB
 
3 members found this post helpful.
  


Reply

Tags
pipewire, pulseaudio


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Pipewire pulseaudio emulation without pulseaudio installed (works) adcdam Slackware 18 04-02-2021 02:34 AM
Plasma 5.20 Beta? It is rock solid, excluding the taskbar thumbnails on Wayland - or rather because Pipewire needs "per user" init scripts LuckyCyborg Slackware 3 09-21-2020 03:50 PM
LXer: This Week in Linux 94: Mesa 20, PipeWire, Linux Be Scary, MyPaint, GTK, Microsoft Defender LXer Syndicated Linux News 0 02-26-2020 08:23 PM
LXer: Improved multimedia support with Pipewire in Fedora 27 LXer Syndicated Linux News 0 09-20-2017 03:54 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:27 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration