Yesterday I started implementing pipewire here on my system and apparently everything worked out. I would love to thank everyone involved on this.

I gave it a general read but basically followed what the OP posted with some basic differences:

1- I made the implementation using Alsa, Pulse, Jack and Pipewire

2- Compiled webrtc audio processing (pulseaudio and pipewire dependency), libldac and libopenaptx (for bluetooth compatible, pipewire dependency)

3- As I need to recompile pulseaudio due to Jack, i already took the opportunity and made the necessary modifications in the pulseaudio .slackbuild as:
4- I also recompiled the pipewire with the necessary modifications and also added ffmpeg in the compilation where it wasn't coming by default (I don't know how much it can improve or worsen)

# Pipewire will control jack use
pipewire-jack.conf content
# Enable mSBC for bluetooth
Apparently it's working using the commands that staff used during the topic
After having performed all this procedure, i noticed two things that i would like to check with you if there is a solution

- I use startx to boot my system and after starting those 3 executables in xdg/autostart my X only goes up after about 10 seconds. Its normal?
- My Redmi AirDots bluetooth headset have a good quality but is only good when there is no crash/acceleration during playback and also when i enable the airdots MIC the quality drops immensely. (Fixed changing my connection to WiFi 5ghz)

My apologies for being so late to the party but some may find this useful.....

https://venam.nixers.net/blog/unix/2...-the-hood.html

So you also read r/linux?

That's a safe bet ;)

Maybe I should have been able to extract the answer from this awesome thread, but here are three questions I have to understand a little better what the inclusion of PipeWire actually means for people like me, who are more or less pure end-users, loving and using Slackware for its stability and low maintenance effort:

In short:
1. Is Pipewire actually used, already, by default in a standard install?
2. What about latencies, if applications use PulseAudio APIs instead of native PipeWire APIs?
3. What applications are actually using PipeWire native APIs already?

In detail:

1. As PipeWire is not part of a standard install in Slackware64-current, is it actually used by anything by default? I don't detect any traces of it in /etc/rc.d, which is probably because it is not a server in the same sense as pulseaudio is. Also, there are (of course) no desktop files. From that I would conclude that PipeWire is included with the distro in order to be prepared for applications that might use the native APIs. But PulseAudio is and will remain the default, for now. Is my (admittedly very superficial) understanding correct?
2. Now, this brings me to my second question. If applications use pulseaudio APIs instead of native PipeWire APIs, doesn't the involved "translation" add latencies? I am asking, because one of the things PA has been criticised for and where PipeWire appears to be better, is too much latency in certain circumstances.
3. Finally, just out of curiosity: What applications included with a Slackware64-current/15 standard install are using PipeWire natively, already?

Thanks!

gargamel

The PipeWire native APIs are used by Wayland/Plasma5 for various features, starting from handling the taskbar thumbnails and ending with desktop sharing. The words "by default" are wrong, because PipeWire is closely integrated on Wayland/Plasma5.

Without the PipeWire daemons running on a Wayland/Plasma5 session, various issues appear starting with no taskbar thumbnails and ending with failures on Chrome/Chromium/Firefox desktop sharing over WebRTC and even TeamViewer or VNCs not working.

Unfortunately, there still missing a software to complete this stack for desktop sharing: xdg-desktop-portal which is frontend of already present xdg-desktop-portal-kde

Regarding the audio latencies, the PipeWire can work realtime, and in fact it was designed being a realtime Audio/Video server, capable to replace both PulseAudio and JACK.

BUT, there still missing a software for this to happen: RtKit, a little daemon invented by no one other than Mr. Poettering. Yeah, the very author of systemd and PulseAudio also written RtKit, which fortunately is a little software which can be installed stand-alone.

With a special note on "I don't detect any traces of it in /etc/rc.d, which is probably because it is not a server in the same sense as pulseaudio is. Also, there are (of course) no desktop files."

The PipeWire daemons aren't supposed to run system-wide, then there never will be something like a /etc/rc.d script for it.

There also are no desktop files on Slackware -current because the Slackware Team looks that considers PipeWire just a hard dependency of the Cinderella Wayland/Plasma5, which of course "is not ready yet for Prime Time" whichever meaning has this.

Yeah, being blunt: they just dumped the PipeWire package on the tree. From orbit. ;)

Greetings!

So, something I just noticed that the desktop files are not set up to work with XFCE. You will need to add the following:
to all 3 desktop files in:
I added mine at the very end of each file. Apologies if this was already mentioned.

xdg-desktop-portal would be a much welcomed addition for us non KDE wayland users :D

About rtKit written by (i dont want to mention him) from pípewire 0.3.29 it say A new module-rt was added to acquire real-time scheduling priviledges without using RTKit.
you can see in releases https://gitlab.freedesktop.org/pipew...ire/-/releases

Adding "OnlyShowIn=XFCE" on the XDG autostart files will make them to be executed only on XFCE sessions.

So, they will not work anymore on Plasma5 no mater if Wayland or X11.

As they are today, they will be executed no matter what DE session will run. Also this is verified practically by myself.

Well, the addition of xdg-desktop-portal will solve certainly the stack for Plasma5, because there's already xdg-desktop-portal-kde

In practice, when an application wants to do screen recording on Wayland/Plasma5, the things works like this:

- the application asks xdg-desktop-portal for a video stream for screen recording
- the xdg-desktop-portal looks for a frontend, and finds running xdg-desktop-portal-kde, so asks it for the video stream
- the xdg-desktop-portal-kde show to user a confirmation dialog (if accepts or not) then asks KWin for the video stream.
- the Kwin setups a new PipeWire video stream and sends the handle to xdg-desktop-portal-kde
- the xdg-desktop-portal-kde sends the handle of video stream (and that information that the user accepted) to xdg-desktop-portal
- the xdg-desktop-portal sends the handle of video stream to application, which then do its job.

All communication is done via DBUS.

Even sounds complicated, this logic ensure that the applications talks always with xdg-desktop-portal no matter which desktop session and implementation runs on the desktop.

So, those who uses different desktop session on Wayland - non Plasma5, will need to run also particular implementations, like xdg-desktop-portal-wlr for WLROOTS based DEs or xdg-desktop-portal-gtk for Wayland/Gnome3.

Interesting, I couldn't get pipewire to work in XFCE without using that in the desktop file.

Thanks @LuckyCyborg This is very interesting. Yes, -wlr is the drone I'm looking for. While I compiled and installed it manually I have virtually no idea how to properly set it up. :)
But I suppose we're getting off topic

Then, maybe you should look on how XFCE handle those XDG autostart files. Could be even a (new) bug.

I am quite sure that, months ago, I had no issues to start the PipeWire daemons on XFCE with those stock XDG autostart files.

When I first tested this, I did so under KDE. So I can't say for sure if this was working at any point with XFCE.

Well, I can confirm you that it works fine even today - with the stock XDG autostart files. I've just tested on full updated system.

I have no idea how to setup xdg-desktop-portal-wlr on Slackware and your particular Wayland DE, BUT I am 100% certain that also xdg-desktop-portal is required.

Well...I need to look at my set up again. I obviously missed something on that system. Thanks for checking your system.

LuckyCybord,

Do you mind sharing one of your pipewire desktop files here? Just want to make sure I am not missing something. Thanks!

Considering that he's the inventor of those XDG desktop files, probably he uses exactly the files described on this thread's first post.

Also myself I use them and if you want a second confirmation, I would like to inform you that the PipeWire daemons runs properly on XFCE also on my mini-PC MinisForum Z83-F.

I've tested this after upgrading to "Tue Jul 6 20:44:20 UTC 2021" updates.

Thanks ZhaoLin. This does help. I'm just perplexed as to why this wasn't working on this particular system. No big deal though. Thanks for chiming in.

As @ZhaoLin1457 already supposed, I use exactly the XDG autostart files described on this thread. There's one, for the sake of fulfilling your request.

/etc/xdg/autostart/pipewire.desktop
Honestly, I believe that your issues are in fact related to how you configured your XFCE - how about to start the XFCE on a new created user, with its default options?

I for one, I suspect that you modified the options of starting services on xfce4-session

https://docs.xfce.org/xfce/xfce4-session/preferences

Let's say that you disabled both the startup of Gnome and KDE services for whatever reasons, because looks like that the XFCE uses "OnlyShowIn" to identify its own services on XDG autostart. ;)

I think you are on to something. This particular account that I am using is old and has seen many instances of xfce. I obviously have something messed up there. I probably should have looked more into that before I chimed here. :) Thank for your tips.

Another data point, but XFCE, pipewire, and SuperCollider started right up. Latency was kind of ass, but I haven't really tuned my laptop for latency. (That is, just default jackdrc, no kernel params yet.)

ETA: I'm not using wayland. Just X. :)

I tried out Pipewire on one of my Test Current installs and thought it might have shown me a way to simplify and improve ALSA interaction with JACK in a Pulse environment. turned out to not work. :( I suppose it was likely just a case of Premature Jack Elation ;)

I've printed out both of these methods, followed the instructions step-by-step and can't get pipewire to work.
Has there been a change in the procedures?
Thanks.

Here's my consolidated instructions that I went through the other day to fix up.

What does not work?

I use with no issues since beginning the "daemon" method of starting the PipeWire daemons from XDG autostart.

Please note that for debugging, you can even execute the commands described on the desktop files on different console tabs, then you can get the messages sent by the PipeWire daemons, which are rather regular programs, with no clues to daemonize themselves.

The proper order of launching their execution is: pipewire, pipewire-media-session, pipewire-pulse

BUT, you should ensure that the PulseAudio server is not (auto-)started.

And of course, you should NOT remove PulseAudio package, because its client libraries and tools are still needed, as usual.

I recently applied it on my new laptop, and no, obviously it hasn't changed
- The 3 pipewire .desktop files in /etc/xdg/autostart/
- autospawn = no in /etc/pulse/client.conf
And in /etc/xdg/autostart/
- mv pulseaudio.desktop pulseaudio.disabled

And everything works as expected

Yep!

With the note that I remembered that I read somewhere that XFCE should be configured to load GNOME/KDE services otherwise it's very picky on executing the XDG files - it loads only those with the following
So, unless the XFCE is configured according, probably we need added on the desktop files at least:
https://specifications.freedesktop.o...atest/apb.html

With the note that OnlyShowIn is not needed on Plasma5 or XFCE with relaxed KDE/GNOME services loading.

FYI pulseaudio.desktop will get reinstalled by the pulseaudo-15 package.

We know. This is one of reasons why I suggested splitting the PulseAudio server in its own package.

But until now looks like my proposal wasn't accepted.

Right
That's why you shouldn't forget to rename the .desktop after each update.
As long as pulseaudio will be the default sound server ...

Who is "we"? You may know, but I didn't see it stated clearly in this pipewire setup thread or the original.

This is more a "slackware" thing than a specific pipewire/pulseaudio one

Who is "we" ? Anybody who used on having interest on running PipeWire as audio-server.

Is obvious that that PulseAudio file for XDG autostart would be reinstalled on package upgrade, even is not stated "clearly" if you have a vague idea what PulseAudio package contains.

Maybe those files could be considered as config files and so we could apply the ".new" stuff as is done for a lot of config files.

Personally, regarding pulseaudio.desktop file, I just copied /etc/xdg/autostart/pulseaudio.desktop to ~/.config/autostart/pulseaudio.desktop then added "Hidden=true" to it. That way, I don't have to remember editing /etc/xdg/autostart/pulseaudio.desktop after upgrading the pulseaudio package. Seems to be working so far for a couple of months here on my system.

How we can do this? To use the PipeWire as audio server, you should disable the PulseAudio server auto-start - and this means also to move away the file /etc/xdg/autostart/pulseaudio.desktop so nothing is on place of it.

Like I said many times, probably the best way is to have the PulseAudio server (and its related files) put in a split package, which can be eventually uninstalled or blacklisted.

It is specific to someone using pipewire on slackware and why we are in this thread. It is also an easy detail to overlook/forget about when updating the system until/if it's a default option.

Obvious if you remember, but very easy to overlook and forget about and anybody new to trying out pipewire on slackware needs to be aware of even if it's just a reminder until pipewire "is" a default configurable option.

Your use of "we" is very contradictory in this case. Remember that not everyone lives and breathes this stuff to the same level/intensity that you appear to do.

That maybe my problem.
I spent a couple hours two weeks ago working on this project, another two or three hours again yesterday and all this morning today and pipewire does not work. There must be something so fundamental that it is obvious to others with more knowledge and experience, but I don't see it.
Are they there any dependencies that are not included with -current?
:scratch:

Do you have something in your : ~/.run ?

This is where pipewire puts its .pid files

Just to be clear...

The PipeWire "daemons" are just ordinary programs, which has no ideas regarding PID files and other daemon-like things. They do not put PID files anywhere.

The one which puts PID files there is our daemon supervisor - the little program which controls the PipeWire "daemons" and executes/stops them as instructed.

However, even for the daemon supervisor those PipeWire daemons are just ordinary programs too and it has nothing to do with PipeWire itself.

It's a generic daemon supervisor, capable to supervise things even on init system - in fact for this purpose it was created years ago.

For example, I have a friend who uses the daemon supervisor to automatically start and stop a VPN client executed on user side.

No such directory.

Great Wizard, the biggest question is: what desktop environment you use?

And IF you use the solution described on OP of this thread and the XFCE as I suspect, did you read my comments regarding XFCE and running its desktop services?

I just set it up on another -current machine without issue.

You should see the following processes and files in ~/.daemon or ~/.run (depending on pidfile location specified)
On my main desktop, which is using digital out, I may have had to configure that output from the Audio control panel again.

Does your audio work without pipewire configured? I had to reinstall alsa-lib and pulseaudio-15 after a recent update (if you haven't been following that recent audio not working thread).

Neither directory exists on this system.
Pulseaudio works just fine.

That will happen if pidfiles isn't specified in either the /etc/daemon.conf.d/pipewire.conf from my example or the "Exec" line in the pipewire*.desktop files from the OG post of this thread. I still got sound but daemon is unable to kill the processes after logging out from that shell.

You did see the 6 daemon/pipewire processes running?

Certainly the best way