Using Pipewire instead of Pulseaudio in Slackware 15

average_user · 05-24-2021, 03:03 PM

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.

average_user · 05-25-2021, 02:24 AM

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.

LuckyCyborg · 05-25-2021, 02:28 AM

Quote:

Originally Posted by average_user

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

average_user · 05-25-2021, 02:54 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.

Candelabrus · 05-28-2021, 02:22 PM

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.

Candelabrus · 06-17-2021, 11:18 AM

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:

Code:

sed -i 's/autospawn = yes/autospawn = no/g' $PKG/etc/pulse/client.conf
rm -rf $PKG/etc/xdg

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)

Code:

    -Dffmpeg=enabled \
    -Dtests=disabled \

Code:

install -Dm644 $CWD/$PRGNAM.desktop $PKG/etc/xdg/autostart/$PRGNAM.desktop
install -Dm644 $CWD/$PRGNAM-pulse.desktop $PKG/etc/xdg/autostart/$PRGNAM-pulse.desktop
install -Dm644 $CWD/$PRGNAM-media-session.desktop $PKG/etc/xdg/autostart/$PRGNAM-media-session.desktop

# Pipewire will control jack use
pipewire-jack.conf content

Code:

/usr/lib64/pipewire-0.3/jack

Code:

install -Dm644 $CWD/pipewire-jack.conf -t $PKG/etc/ld.so.conf.d

# Enable mSBC for bluetooth

Code:

sed -i 's/#bluez5.msbc-support = false/bluez5.msbc-support = true/g' $PKG/usr/share/pipewire/media-session.d/bluez-monitor.conf

Apparently it's working using the commands that staff used during the topic

Code:

ldd /usr/bin/qjackctl | grep -i libjack
	libjack.so.0 => /usr/lib64/libjack.so.0 (0x00007f3d0dd42000)

Code:

eric@slackware ~ ps -ef | grep pipewire
eric      1377  1329  0 jun18 tty1     00:00:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
eric      1381  1377  3 jun18 tty1     00:00:46 pipewire-pulse: /usr/bin/pipewire-pulse
eric      1391  1329  0 jun18 tty1     00:00:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
eric      1395  1329  0 jun18 tty1     00:00:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session
eric      1398  1391  1 jun18 tty1     00:00:16 pipewire: /usr/bin/pipewire
eric      1407  1395  1 jun18 tty1     00:00:22 pipewire-media-session: /usr/bin/pipewire-media-session
eric      3461  3451  0 00:12 pts/0    00:00:00 grep pipewire

Code:

eric@slackware ~ inxi -F
System:
  Host: slackware.com Kernel: 5.12.11 x86_64 bits: 64 
  Desktop: Cinnamon 4.8.6 Distro: Slackware 14.2 
Machine:
  Type: Laptop System: ASUSTeK product: X510URR v: 1.0 
  serial: <superuser required> 
  Mobo: ASUSTeK model: X510URR v: 1.0 serial: <superuser required> 
  UEFI: American Megatrends v: X510URR.309 date: 04/19/2019 
Battery:
  ID-1: BAT0 charge: 28.8 Wh (100.0%) condition: 28.8/42.1 Wh (68.5%) 
  volts: 11.5 min: 11.5 
CPU:
  Info: Quad Core model: Intel Core i5-8250U bits: 64 type: MT MCP cache: 
  L2: 6 MiB 
  Speed: 800 MHz min/max: 400/3400 MHz Core speeds (MHz): 1: 800 2: 800 
  3: 800 4: 800 5: 800 6: 800 7: 800 8: 800 
Graphics:
  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel 
  Device-2: NVIDIA GM108M [GeForce 930MX] driver: N/A 
  Device-3: IMC Networks USB2.0 VGA UVC WebCam type: USB driver: uvcvideo 
  Display: server: X.Org 1.20.11 driver: loaded: modesetting unloaded: vesa 
  resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2) v: 4.6 Mesa 21.1.2 
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio driver: snd_hda_intel 
  Sound Server-1: ALSA v: k5.12.11 running: yes 
  Sound Server-2: PipeWire v: 0.3.30 running: yes
Network:
  Device-1: Intel Wireless 7265 driver: iwlwifi 
  IF: wlan0 state: up mac: xx:xx:xx:xx:xx:xx

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)

enorbet · 06-24-2021, 01:21 AM

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

average_user · 06-24-2021, 02:48 AM

So you also read r/linux?

enorbet · 06-24-2021, 03:05 PM

Quote:

Originally Posted by average_user

So you also read r/linux?

That's a safe bet

gargamel · 07-02-2021, 04:51 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?

Thanks!

gargamel

LuckyCyborg · 07-02-2021, 10:39 AM

Quote:

Originally Posted by gargamel

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.

stormtracknole · 07-06-2021, 12:29 PM

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:

Code:

OnlyShowIn=XFCE;

to all 3 desktop files in:

Code:

/etc/xdg/autostart

I added mine at the very end of each file. Apologies if this was already mentioned.

tramtrist · 07-06-2021, 12:32 PM

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

adcdam · 07-06-2021, 01:09 PM

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

LuckyCyborg · 07-06-2021, 01:36 PM

Quote:

Originally Posted by stormtracknole

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:

Code:

OnlyShowIn=XFCE;

to all 3 desktop files in:

Code:

/etc/xdg/autostart

I added mine at the very end of each file. Apologies if this was already mentioned.

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.