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.
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:
Code:
[I][000033735.394120][backend-native.c:453 device_supports_required_mSBC_transport_modes()] native: bluetooth host adapter not capable of eSCO link mode (LMP_ESCO)
This is the dongle I use:
Code:
Bus 003 Device 030: ID 1131:1004 Integrated System Solution Corp. Bluetooth Device
Now I'm thinking about getting a newer dongle but which one should I get? It's a lottery.
Last edited by average_user; 05-24-2021 at 04:13 PM.
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.
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:
Code:
[I][000033735.394120][backend-native.c:453 device_supports_required_mSBC_transport_modes()] native: bluetooth host adapter not capable of eSCO link mode (LMP_ESCO)
This is the dongle I use:
Code:
Bus 003 Device 030: ID 1131:1004 Integrated System Solution Corp. Bluetooth Device
Now I'm thinking about getting a newer dongle but which one should I get? It's a lottery.
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...
Last edited by LuckyCyborg; 05-25-2021 at 02:37 AM.
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.
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)
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)
Last edited by Candelabrus; 06-19-2021 at 12:23 AM.
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:
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?
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.
Finally, just out of curiosity: What applications included with a Slackware64-current/15 standard install are using PipeWire natively, already?
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:
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?
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.
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.
Last edited by LuckyCyborg; 07-02-2021 at 10:57 AM.
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.