Using Pipewire instead of Pulseaudio in Slackware 15
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi! Just tried out the pipewire-enable.sh and while I get sound in my Plasma session I do not get sound output or alsamixer does not work before I log in to X. I tried to reboot to see if that was a issue but it persists. Is there any way to enable sound in the console?
Also sometimes sound and graphics will freeze while changing the volume using requiring me to kill pipewire to get things back to normal. These problems do not exist using pulseaudio.
The issue is that pipewire does not manage its own daemons' starting/stopping (pulseaudio does, pipewire does not afaik). Pipewire expects something like the service manager side of systemd to do daemon management in the way its designed. You can start the daemons manually and background them at the console to get them to run, but they will not terminate at logout so you will have to do that manually yourself, use a bash_logout script, or use 'daemon'***.
***Slackware added the 'daemon' program to manage the pipewire daemons. This 'daemon' program is able to terminate any daemons it manages at session close by working with elogind. Basically you launch the pipewire daemons wrapped in 'daemon's syntax and the rest should be taken care of automatically. To see an example of this, read the /etc/xdg/autostart/pipewire*.desktop files' 'Exec' lines:
The way Slackware is set up, it only runs the pipewire daemons from those xdg autostart files. This limits their use to xdg autostart compliant desktops, meaning pipewire will not start for console logins, or window manager's without xdg-autostart (though that can be added in with 'fbautostart').
FWIW, the pipewire daemons will still run properly from console and audio works fine when I've used it that way. It would be nice if the daemon management solution was more "universal" for the benefit of these other session types, but I guess the target users of pipewire are desktop users.
... I guess the target users of pipewire are desktop users.
Precisely. And especially -Slackware- Wayland users
Code:
PipeWire is a project that aims to greatly improve handling of audio and video under Linux.
It provides a low-latency, graph-based processing engine on top of audio and video devices
that can be used to support the use cases currently handled by both PulseAudio and JACK.
PipeWire was designed with a powerful security model that makes interacting with audio and
video devices from containerized applications easy, with support for Flatpak applications
being the primary goal. Alongside Wayland and Flatpak, we expect PipeWire to provide a core
building block for the future of Linux application development.
I highly doubt I need a clean installation. However, I do think you are on to something when you spoke of hardware, that being not necessarily an incompatibility but more than likely something at the internal firmware level when handling certain types of media. What I am talking of actually happens after a base install, it's not bad it's just that I tend to be sensitive to even the slightest subtly of sound transition, my ears have been slowly trained over the years and it actually doesn't happen in my preferred DAW environments.
And! Just for a sanity check and for a wee bit of science sake, I just came back from Windows to test it with a certain number of things 'same issues', it's interface level, most likely the very design of the device, or even how certain applications are coded when it comes to audio. I rarely use Windows except for testing certain problems when in doubt.
I probably just started noticing the stuff this year and did not pay any attention to it before.
Issue on my end solved.
The point is moot now, but I didn't mean a reinstall if that's how you understood it. Anyway, the more important point was the first one about making sure alienbob's pipewire-jack matches the version of pipewire you are using.
The point is moot now, but I didn't mean a reinstall if that's how you understood it. Anyway, the more important point was the first one about making sure alienbob's pipewire-jack matches the version of pipewire you are using.
What you actually said is a good practice concerning packages, I see where you were coming from on the other bit. I don't have pipewire-jack installed on current though, cause it allows me to start jackdbus aka jack2 without it. As a default sound server I have no complaints, it just works. Here is something really entertaining about it, in System Shock Enhanced Edition in lutris with jack not started I am still able to start a fluildsynth server and connect it to wine midi for that game and get the midi music going, which is notorious for not working by default, I alt+tab out to do it in the qjackctl connection graph. Pretty interesting. With pulseaudio you can't do that and have a clean exit without it hanging.
The real aim is for it to replace all of it though jack2 included, I am sure you already know that, was mentioned again above.
Last edited by slackdruid; 10-18-2023 at 10:18 AM.
What you actually said is a good practice concerning packages, I see where you were coming from on the other bit. I don't have pipewire-jack installed on current though, cause it allows me to start jackdbus aka jack2 without it. As a default sound server I have no complaints, it just works. Here is something really entertaining about it, in System Shock Enhanced Edition in lutris with jack not started I am still able to start a fluildsynth server and connect it to wine midi for that game and get the midi music going, which is notorious for not working by default, I alt+tab out to do it in the qjackctl connection graph. Pretty interesting. With pulseaudio you can't do that and have a clean exit without it hanging.
The real aim is for it to replace all of it though jack2 included, I am sure you already know that, was mentioned again above.
I think that's the great thing about pipewire, is that generally it just works and it also plays well with others. Works well with different clock rates, which is my main ask of it...for some higher bitrate flacs over spdif to my stereo.
The issue is that pipewire does not manage its own daemons' starting/stopping (pulseaudio does, pipewire does not afaik). Pipewire expects something like the service manager side of systemd to do daemon management in the way its designed. You can start the daemons manually and background them at the console to get them to run, but they will not terminate at logout so you will have to do that manually yourself, use a bash_logout script, or use 'daemon'***.
***Slackware added the 'daemon' program to manage the pipewire daemons. This 'daemon' program is able to terminate any daemons it manages at session close by working with elogind. Basically you launch the pipewire daemons wrapped in 'daemon's syntax and the rest should be taken care of automatically. To see an example of this, read the /etc/xdg/autostart/pipewire*.desktop files' 'Exec' lines:
The way Slackware is set up, it only runs the pipewire daemons from those xdg autostart files. This limits their use to xdg autostart compliant desktops, meaning pipewire will not start for console logins, or window manager's without xdg-autostart (though that can be added in with 'fbautostart').
FWIW, the pipewire daemons will still run properly from console and audio works fine when I've used it that way. It would be nice if the daemon management solution was more "universal" for the benefit of these other session types, but I guess the target users of pipewire are desktop users.
Location: The Glorious People's Republic of Austin
Posts: 178
Rep:
Sorry to necro-bump this thread, but as it pertains to using PipeWire with Slackware, has anyone had any luck getting screensharing to work on Wayland in -current? I have PipeWire enabled according to the instructions at the beginning of this thread, and audio is working as expected with PipeWire, but any time I try to load the screenshare from the Mozilla WebRTC test page, I get the following error:
Code:
xdp-kde-screencast: zkde_screencast_unstable_v1 does not seem to be available
Also relevant, I can see this error in the wayland-session.log right at startup:
Code:
(/usr/libexec/xdg-desktop-portal:3120): xdg-desktop-portal-WARNING **: 14:05:26.017: Failed connect to PipeWire: Couldn't connect to PipeWire
As I mentioned, audio still works fine, and alsamixer displays PipeWire as the default output, so it seems to work for everything but screenshare. That makes me think that PipeWire needs to start before xdg-desktop-portal-kde is loaded, but I am not sure how best to achieve that, since the current method of loading PipeWire on Slackware involves leveraging xdg-autostart.
Has anyone gotten screensharing working on -current? If so, how?
When running a "full wayland session", a KDE popup will appear after allowing permission to screen share. Once a window or screen is selected, the test shows the screen properly.
With the other type of plasma wayland session, nothing appears after granting permission.
I'm not sure what the differences are between "wayland" and "full wayland", but the problem seems to be there with plasma/wayland/pipewire/portal screen sharing.
Most of the time I run gnome on slackware, which also has working screen sharing on -current with pipewire and wayland. Maybe one of the kde gurus will be able to shed some light on what the difference with wayland and full wayland are.
I'm not sure what the differences are between "wayland" and "full wayland", but the problem seems to be there with plasma/wayland/pipewire/portal screen sharing.
Most of the time I run gnome on slackware, which also has working screen sharing on -current with pipewire and wayland. Maybe one of the kde gurus will be able to shed some light on what the difference with wayland and full wayland are.
It is a method to build Qt5 and KDE Frameworks packages, borrowed by LuckyCyborg from openSUSE.
Practically, by default the Qt5 library lets programs choose whether to use the X11 platform via XWayland or the native Wayland platform.
This is Plasma5's standard Wayland session. While "Full Wayland" forces the use of the native Wayland platform for all programs.
I think that letting the programs choose whether to use the X11 platform via XWayland or the native Wayland platform is a sensible choice, considering when it was introduced, a few years ago. In the end, Firefox did not get Wayland support by default until Firefox 120, which is not yet part of Slackware, neither -stable nor -current. And the examples could go on.
I think everyone should use the Wayland session version that suits them better. In the end, the Full Wayland sessions forces these environment variables bellow
Code:
GDK_BACKEND=wayland
QT_QPA_PLATFORM=wayland
Last edited by ZhaoLin1457; 11-26-2023 at 09:22 PM.
This hit the nail on the head. After a little testing, adding 'QT_QPA_PLATFORM=wayland' to the .desktop file in /usr/share/wayland-sessions got screensharing working here. It's a little weird, because I am pretty sure it also gets exported when Plasma initializes. I guess it just needs to be a little earlier...
This hit the nail on the head. After a little testing, adding 'QT_QPA_PLATFORM=wayland' to the .desktop file in /usr/share/wayland-sessions got screensharing working here. It's a little weird, because I am pretty sure it also gets exported when Plasma initializes. I guess it just needs to be a little earlier...
In fact, the Firefox distributed by Slackware uses X11 via XWayland, unless instructed otherwise. Probably you want GDK_BACKEND=wayland
Location: The Glorious People's Republic of Austin
Posts: 178
Rep:
Quote:
Originally Posted by ZhaoLin1457
In fact, the Firefox distributed by Slackware uses X11 via XWayland, unless instructed otherwise. Probably you want GDK_BACKEND=wayland
I have MOZ_ENABLE_WAYLAND=1 set in my .bash_profile for my wayland sessions, which loads both firefox and thunderbird in Wayland instead of XWayland:
Code:
if [ "$XDG_SESSION_TYPE" = "wayland" ]; then
export MOZ_ENABLE_WAYLAND=1
fi
In any case, per my last update, just setting 'env QT_QPA_PLATFORM=wayland' in the Exec line of /usr/share/wayland-sessions/plasmawayland.desktop is sufficient to get screensharing working. I might do some more testing with the Full Wayland session type later, but GTK still feels iffy on Wayland, despite the recent leaps forward.
This is a preliminary release of WirePlumber 0.5.0, which is made available
for testing purposes. Please test it and report feedback (merge requests are
also welcome 😉). This is not API/ABI stable yet and there is still pending
work to do before the final 0.5.0 release, both in the codebase and the
documentation.
This is a preliminary release of WirePlumber 0.5.0, which is made available
for testing purposes. Please test it and report feedback (merge requests are
also welcome 😉). This is not API/ABI stable yet and there is still pending
work to do before the final 0.5.0 release, both in the codebase and the
documentation.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
