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:
pipewire.desktop
pipewire-pulse.desktop
pipewire-media-session.desktop
Then, you need to edit:
and change:
to
Remove, or place:
in a backup directory somewhere else. Thanks to LuckyCyborg for this suggestion.

Log out and log back in. You should now see pipewire running:
I modified LuckyCyborg's daemon SlackBuild to include these files along the changes needed for pulse.

SlackBuild:
doinst.sh
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.

This is awesome. Thank you!

@stormtracknole

You got right the PipeWire setup! Congratulations! :hattip:

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. :D

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. :/

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? :p

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?

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!!

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.

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.

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. :)

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..

Hello,

Another less intrusive solution is to copy /etc/xdg/autostart/pulseaudio.desktop in ~/.config/autostart, and add the following line in the copy :

--
SeB

@chemfire

Did you know what PipeWire replaces for using with the PulseAudio linked applications as usual?

It have an audio server: pipewire-pulse which is a one-to-one replacement of the PulseAudio server. That's all.

The applications believes that they talks with your regular PulseAudio server, and they are linked against PulseAudio library.

So, this Pulse-to-Pipewire bridge about you talk assumes that PipeWire is a totally different thing of PulseAudio.

It's NOT. The PipeWire is just a very improved PulseAudio - like I said, realtime and with Video streams support.

Heck, even its original name was PulseVideo. Go figure!

I believe that's WHY also only few applications tried to support the native PipeWire audio APIs until now.
That's what believes a PulseAudio-powered application that it talks to: PulseAudio 14.0.0

Then the only correct solution would be to make a Pipeware default out of the box in Slackware 15.

Honestly, I believe that our BDFL will leave Fedora to train this dragon first... ;)

BUT, probably is not so long in the future the time when the PipeWire will be the default audio-server, because the PipeWire already does a fine job (also as audio server) and the migration is very simple: just replace that audio server which is running - you do not need to patch and recompile half of distro.

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.

My understanding; I have not tried to run pipewire yet; is that yes it provides a pulse audio server interface. Don't you still have to have the pulse audio libraries present on the system though? Does pipewire provide a replacement library with a compatible API to link at build time for applications that were written with only pulse in mind?

The PipeWire replaces the PulseAudio server, BUT the applications still needs to be linked against the PulseAudio libraries and those libraries to be present.

Then, the PulseAudio C/C++ headers are still needed, also everything else - e.g. the tools.

Long story short: on PipeWire are no compat libraries/headers to replace PulseAudio, only a compat audio server: pipewire-pulse.

True, the applications may choose to migrate to the native APIs of PipeWire, which of course aren't compatible with PulseAudio.

Thanks for the clarification. I thought that was how it probably worked. Great work on this by the way. Huge benefit to the rest of us to have script to follow and an idea of what is coming.

Oss still works (ossv4) , i installed it last year in Gentoo, http://ossnext.trueinstruments.com/f...39034b83c715f7 ,
i compiled a kernel without Alsa support and tested it, i got sound in Mpv, Mpd and Wine, although i had to change a lot of config files.
i have Pipewire Fedora packages installed in Slackware current. if you want just the pulseaudio libraries you can install https://rpmfind.net/linux/rpm2html/s...ulseaudio-libs package pulseaudio-libs or make your own package with those libs. https://fedora.pkgs.org/33/fedora-up...86_64.rpm.html.
and there is also sndio for other uses.

Since ALSA is mentioned, it could also be mentioned it has seen "tons" of fixes according to many recent changelogs...

Carry on with this until now excellent thread! :D

why until now?

That's all well and good, I guess(!?), since those who answered my post decided to talk over my head and not actually answer my question (and didn't mean to start any flame war!) which was:

If it's supposedly so easy to implement any of these things (then again, one of the replies to my post made it seem like the world would explode if anything other than X were now used - that's how *I* interpreted the reply. I did express that I was very ignorant of things programming), why can't they be offered as three choices during installation? Don't rag on me just because *YOU* don't like that I, a plain ol' everyday user of Slackware, don't happen to like 'X' whatever. I asked a simple question. I know it's probably *NOT* as simple as it was made to look by the posts I've already pointed out saying it is, but don't talk over my head or down to me and just answer, if possible, if (and why would be nice too, unless that's a programming thing that will make me look cross-eyed after two sentences being read, heh) it can or can't be done.

[QUOTE]i can not ask or there are better people suited to ask your question, im using Slackware current since only a few months ago, there is no choice between just plain alsa and pulseaudio or pipewire in Slaxkware because thats what was choosen, For example in Gentoo you want to use only Alsa you can but Gentoo is a system were you compile everthing.
for example the firefox binary has not support for alsa backend if you use Firefox-bin in Gentoo and you dont have pulseaudio or pipewire you got no sound. if you compile firefox with alsa support you got sound. https://github.com/mozilla/cubeb/wiki/Backend-Support. Pulseaudio was choosen because its what most use. In another distro for example Void Linux they have sndio and firefox sound backend.
its a matter of developers i think if you want more support perhaps you can learn and contribute to Slackware. you can compile your own packages with only Alsa support but you are on your own in that case.
the best thing you can do is learn so you will have more choices and not have what everyone else have.
In my case in Slackware im using pipewire and for example in Steam im having less problems than using just plain alsa.
i ll install ossv4 2019 version to test how it work or if it work in steam.
pulseaudio and pipewire both work on top of Alsa, Ossv4 works on its own, Oss was the default sound for linux until the devolpers decided that their program will not be opensource and that pisded off Linus Torvals and got rid of oss from the kernel, years later Oss went open source again but it was late.
sndio is from bsd and was ported to linux.
Pipewire at least is developed by a very good programmer called Wim Taymans who also created gstreamer i was told by a forum member (i dont know if he is human or a cyborg but he is very lucky) that he likes to share a beer with a guy called Lennart...:D

Hi FTIO! I hope my post wasn't taken out of context. You are bringing good points. Obviously, Pat would decide how things are implemented. These steps I provided (with everyone's help) shows how to achieve that. I can see staying with Pulse by default and switch to Pipewire in 15.1. At least the options are there now for both which I am quite happy about. :)

Hey, people!

I will translate this thread title properly for you:

Using PulseAudio V2 instead of PulseAudio V1 in Slackware 15

You are kind now to go and open your own thread about "PulseAudio sucks" , please?

Feel free to beat this dead horse bones again. BUT, elsewhere!

Hello! Using PipeWire does NOT mean PulseAudio sucks!

Now we can talk with tranquility about how cool is PulseAudio and its successor?

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.

where?:D:D

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:
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.

:hattip:

Thank you everyone! And thanks to whoever coded Pulse to allow for this (code from default.pa and system.pa):
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.

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.

Thanks again for the answer.

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.

Hi,

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)

Thank you very much ZhaoLin1457 & LuckyCyborg

My laptop, for information (If it can be useful):

Shameless plug (Posted on Feb 03, 2021):

https://www.linuxgalaxy.org/bkoenig/...with-pipewire/

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:

https://github.com/raforg/daemon/issues/1

So, you can believe me that before of this date I have managed to start PipeWire, long enough to understand the caveats?

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.

very nice blog, man!

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!

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
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.

Here's a semi-official answer on what codecs out headphones support: https://community.bose.com/t5/Headph...ort/td-p/58799

This is not what I meant - I can use SBC in High Fidelity Playback too but I'm asking about mSBC that is used in Hands-Free Profile.

OK, now I think that it's a fault of my old low-quality Bluetooth USB dongle. I see this in pipewire-media-session logs:

This is the dongle I use:

Now I'm thinking about getting a newer dongle but which one should I get? It's a lottery.

mSBC works on my work laptop, finally Bluetooth headphones microphone became usable on Linux. I found out that mSBC has also been implemented in PulseAudio too.

I for one, I will buy any cheap Chinese dongle which advertise Bluetooth 5.0 but feel free to buy a more expensive one. Any of them should work.

BTW, yours one has support for Bluetooth 2.0, so I doubt that it support duplex links or properly works on today Linux...

Yeah, this dongle is more than 10 years old but as I said now I'm sure that pipewire works correctly on my work laptop. I am now satisfied because I mostly need Bluetooth microphone for online meetings at work.

When did you mention that ffmpeg was built with support for pipewire that was more specifically made? Because i opened the Current source and didn't notice anything different in the build.