Downgrading pipewire for testing regression

Greetings lovely community,

Been using pipewire for a couple months, some minor hiccups along the way, but it’s more or less worked decent enough (still needs some work if I’m honest). Recently I’ve been having some audio issues since last week and I think it’s because of the pipewire 1:0.3.52-1 update from June 10’th. My current issue is whenever I play some music (I’m always using a bluetooth UE Boom 2 speaker) in Rhythmbox, pause it, then say play a podcast in Gnome Podcast, the audio jumps to 100% for less than a second before going back to the correct volume I had it at which is around 30% volume. This is extremely jarring and unsettling to say the least. Sometimes when I’m pausing/unpausing/skipping audio in Rhythmbox, this same effect will happen where the audio jumps to 100% and then immediately drops back down to the correct audio level that it should be at.

If I’m just playing music continually, the effect does not happen. It seems to only be reproducible when starting/stopping some type of audio. This issue was not happening over a week ago, so I believe it’s more than likely a bug/regression in pipewire, but I would like to try downgrading just to be sure if I can reproduce it or not. I’m running wireplumber as well, but this issue also happens when testing it on pipewire-media-session too. I didn’t see this exact issue up on Pipewire’s git page, so I figured I might as well try a downgrade first.

When using my bluetooth on Gnome, under Sound settings, this is my configuration for it. I can use either SBC or SBC-XQ codecs as they produce the best audio quality, and from my limited testing for this issue, it seems it happens more frequently under SBC so I’ve opted to use SBC-XQ instead, but the issue still does happen on both unfortunately.

Screenshot from 2022-06-14 15-10-28

Admittedly, I’ve never had the need to downgrade a package before, so I’m wondering if there’s anything I need to do or consider besides running downgrade pipewire ? Pipewire is required by mutter, wireplumber, and a few others. Will downgrading pipewire also downgrade any of it’s dependencies too or no? Would just really like to downgrade pipewire to see if that is indeed the problematic package or not. This issue also happens on Zen, LTS, and Linux kernels btw. Thanks for any helpful advice!

[scott@EndeavourOS ~]$ pacman -Qi pipewire
Name            : pipewire
Version         : 1:0.3.52-1
Description     : Low-latency audio/video router and processor
Architecture    : x86_64
URL             : https://pipewire.org
Licenses        : MIT  LGPL
Groups          : None
Provides        : libpipewire-0.3.so=0-64
Depends On      : alsa-card-profiles  libdbus-1.so=3-64  libncursesw.so=6-64
                  libsndfile.so=1-64  libudev.so=1-64  libusb-1.0.so=0-64
                  libasound.so=2-64  libsystemd.so=0-64  libbluetooth.so=3-64
                  libsbc.so=1-64  libldacBT_enc.so=2-64  libfreeaptx.so=0-64
                  libfdk-aac.so=2-64  liblilv-0.so=0-64
                  libwebrtc_audio_processing.so=1-64
Optional Deps   : pipewire-docs: Documentation
                  pipewire-session-manager: Session manager [installed]
                  pipewire-alsa: ALSA configuration [installed]
                  pipewire-jack: JACK support [installed]
                  pipewire-pulse: PulseAudio replacement [installed]
                  gst-plugin-pipewire: GStreamer plugin [installed]
                  pipewire-zeroconf: Zeroconf support
                  pipewire-v4l2: V4L2 interceptor
                  pipewire-x11-bell: X11 bell
                  realtime-privileges: realtime privileges with rt module
                  rtkit: realtime privileges with rtkit module [installed]
Required By     : gst-plugin-pipewire  mutter  pipewire-jack  pipewire-pulse
                  wireplumber  xdg-desktop-portal
Optional For    : sdl2
Conflicts With  : None
Replaces        : None
Installed Size  : 8.03 MiB
Packager        : David Runge <dvzrv@archlinux.org>
Build Date      : Thu 09 Jun 2022 08:06:12 AM EDT
Install Date    : Fri 10 Jun 2022 12:45:59 PM EDT
Install Reason  : Installed as a dependency for another package
Install Script  : Yes
Validated By    : Signature

These are all the packages that got updated on June 10th if that helps narrow anything down a bit:

[2022-06-10T14:08:02-0400] [ALPM] upgraded linux-zen-headers (5.18.2.zen1-1 -> 5.18.3.zen1-1)
[2022-06-10T14:08:00-0400] [ALPM] upgraded linux-zen (5.18.2.zen1-1 -> 5.18.3.zen1-1)
[2022-06-10T14:07:58-0400] [ALPM] upgraded egl-wayland (2:1.1.9+r3+g582b2d3-1 -> 2:1.1.10-1)
[2022-06-10T14:07:58-0400] [ALPM] upgraded linux-headers (5.18.2.arch1-1 -> 5.18.3.arch1-1)
[2022-06-10T14:07:56-0400] [ALPM] upgraded linux (5.18.2.arch1-1 -> 5.18.3.arch1-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded lib32-mesa (22.1.1-1 -> 22.1.1-2)
[2022-06-10T12:45:59-0400] [ALPM] upgraded smbclient (4.16.1-3 -> 4.16.1-4)
[2022-06-10T12:45:59-0400] [ALPM] upgraded pipewire-pulse (1:0.3.51-1 -> 1:0.3.52-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded pipewire-jack (1:0.3.51-1 -> 1:0.3.52-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded pipewire-alsa (1:0.3.51-1 -> 1:0.3.52-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded libcups (1:2.4.2-2 -> 1:2.4.2-3)
[2022-06-10T12:45:59-0400] [ALPM] upgraded ldb (2:2.5.0-1 -> 2:2.5.1-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded tdb (1.4.6-1 -> 1.4.7-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded tevent (1:0.11.0-3 -> 1:0.12.1-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded talloc (2.3.3-3 -> 2.3.4-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded gst-plugin-pipewire (1:0.3.51-1 -> 1:0.3.52-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded mesa (22.1.1-1 -> 22.1.1-2)
[2022-06-10T12:45:59-0400] [ALPM] upgraded pipewire (1:0.3.51-1 -> 1:0.3.52-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded alsa-utils (1.2.6-1 -> 1.2.7-1)
[2022-06-10T12:45:59-0400] [ALPM] upgraded alsa-lib (1.2.6.1-1 -> 1.2.7-2)
[2022-06-10T12:45:59-0400] [ALPM] upgraded alsa-ucm-conf (1.2.6.3-1 -> 1.2.7-1)
[2022-06-10T12:45:58-0400] [ALPM] upgraded alsa-card-profiles (1:0.3.51-1 -> 1:0.3.52-1)
[2022-06-10T12:45:58-0400] [ALPM] upgraded wireless-regdb (2022.04.08-1 -> 2022.06.06-1)
[2022-06-10T12:45:58-0400] [ALPM] upgraded linux-lts-headers (5.15.45-1 -> 5.15.46-1)
[2022-06-10T12:45:56-0400] [ALPM] upgraded linux-lts (5.15.45-1 -> 5.15.46-1)

FWIW 1:0.3.52-2 just landed for me. Might help!?

2 Likes

Is your BT audio driver ok?
inxi -Fzxa

  • check for Bluetooth section.

What does your
systemctl --user status | grep wire
produce?

1 Like

As a user who suffers greatly from chronic-updater-itis, I did not see this update, though I had checked the Arch website not even an hour ago to see if the pipewire package was outdated or not and it was up to date. Ah well, in any case, let me try installing these updates, rebooting, and see how it does because this would absolutely make my day if I don’t have to do anymore tinkering :clown_face: :sweat_smile:

@anon11595408 thanks for the reply, lemme just get fully up to date and I’ll see if it fixes it or not and report back in a few moments.

1 Like

@keithy Sadly that v1:0.3.52-2 update did not fix it at all, oh my poor ears :sweat_smile:

@anon11595408

inxi -Fzxa
Bluetooth:
  Device-1: Intel Wireless-AC 3168 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 1-5:3 chip-ID: 8087:0aa7 class-ID: e001
  Report: rfkill ID: hci0 rfk-id: 0 state: up address: see --recommends
[scott@EndeavourOS ~]$ systemctl --user status | grep wire
             ├─pipewire-pulse.service
             │ └─1246 /usr/bin/pipewire-pulse
             ├─pipewire.service
             │ └─1244 /usr/bin/pipewire
             │ └─4584 grep wire
             ├─wireplumber.service
             │ └─1245 /usr/bin/wireplumber

Both outputs look ok and totally normal to me. BT in general appears to remain an issue for us Linux users, although many things have been fixed over the years… what else can I say at my witt’s ending.

Try a downgrade? Maybe, Gnome is somewhat lagging behind, as per what you describe in your OP.

(Keep us posted.)

Really weird behavior, but I can reproduce it 100%, when starting/stopping audio the issue happens still. However, for reasons unknown to me, when I have Gnome Settings > Sound tab open, the sound issue is no longer reproducible and the audio levels all function normally. The second I close Gnome Settings, the audio issue is once again immediately reproduce. This “fix” only works when the Gnome Settings > Sound tab is displayed, switching to any other Gnome Settings option will make the sound issue happen again. Any thoughts on pipewire being tied to Gnome Settings, but only when it’s open? I can post a video if that’s helpful at all, it’s just really weird.

1 Like

No need for video. I trust your saying. I had similar issues (on a totally different ballpark, gnome settings for printers opened and unlocked) with Selinux errors on Fedora today… i.e. I had to have the printer settings unlocked, while solving an error, otherwise the error would persist.

Gnome IS A BEAST to handle in some cases.

Which leads me to think…

what if… you install another DE alongside and listen there. All your troubles could be gone on Xfce. Or?!

It’s more than likely possibly a Gnome specific bug, bluetooth on Gnome 42 has not been an easy picnic, compared to Gnome 40/41, which just worked with zero issues. I’d rather keep it simple and downgrade one package, than install a whole DE just to test something out :sweat_smile:

But in any case, is it just as simple as downgrade pipewire? I have at least 3 versions of it in my cache I’m sure

Somewhat sorry here to say, ‘Seek and ye shall find.’

@Scotty_Trees - Gnome42 is introducing it’s own ‘immutability’ of a kind… so I wouldn’t bet on your last question.

A bit-o-Googling and some Endeavour/Arch Wiki/Reddit reading and I think I got this downgrade process figured out in regards to pipewire:

First let’s figure out all the packages besides pipewire that I may need to also downgrade:

[scott@EndeavourOS ~]$ pacman -Qe | grep pipewire
gst-plugin-pipewire 1:0.3.52-2
pipewire-alsa 1:0.3.52-2
pipewire-jack 1:0.3.52-2
pipewire-pulse 1:0.3.52-2

Ok so I’ll have to downgrade 5 packages to test this out. Do I have some cache files for pipewire? Let’s find out with:

[scott@EndeavourOS ~]$ ls /var/cache/pacman/pkg | grep pipewire
gst-plugin-pipewire-1:0.3.51-1-x86_64.pkg.tar.zst
gst-plugin-pipewire-1:0.3.51-1-x86_64.pkg.tar.zst.sig
gst-plugin-pipewire-1:0.3.52-1-x86_64.pkg.tar.zst
gst-plugin-pipewire-1:0.3.52-1-x86_64.pkg.tar.zst.sig
gst-plugin-pipewire-1:0.3.52-2-x86_64.pkg.tar.zst
gst-plugin-pipewire-1:0.3.52-2-x86_64.pkg.tar.zst.sig
pipewire-1:0.3.51-1-x86_64.pkg.tar.zst
pipewire-1:0.3.51-1-x86_64.pkg.tar.zst.sig
pipewire-1:0.3.52-1-x86_64.pkg.tar.zst
pipewire-1:0.3.52-1-x86_64.pkg.tar.zst.sig
pipewire-1:0.3.52-2-x86_64.pkg.tar.zst
pipewire-1:0.3.52-2-x86_64.pkg.tar.zst.sig
pipewire-alsa-1:0.3.51-1-x86_64.pkg.tar.zst
pipewire-alsa-1:0.3.51-1-x86_64.pkg.tar.zst.sig
pipewire-alsa-1:0.3.52-1-x86_64.pkg.tar.zst
pipewire-alsa-1:0.3.52-1-x86_64.pkg.tar.zst.sig
pipewire-alsa-1:0.3.52-2-x86_64.pkg.tar.zst
pipewire-alsa-1:0.3.52-2-x86_64.pkg.tar.zst.sig
pipewire-jack-1:0.3.51-1-x86_64.pkg.tar.zst
pipewire-jack-1:0.3.51-1-x86_64.pkg.tar.zst.sig
pipewire-jack-1:0.3.52-1-x86_64.pkg.tar.zst
pipewire-jack-1:0.3.52-1-x86_64.pkg.tar.zst.sig
pipewire-jack-1:0.3.52-2-x86_64.pkg.tar.zst
pipewire-jack-1:0.3.52-2-x86_64.pkg.tar.zst.sig
pipewire-media-session-1:0.4.1-2-x86_64.pkg.tar.zst
pipewire-media-session-1:0.4.1-2-x86_64.pkg.tar.zst.sig
pipewire-pulse-1:0.3.51-1-x86_64.pkg.tar.zst
pipewire-pulse-1:0.3.51-1-x86_64.pkg.tar.zst.sig
pipewire-pulse-1:0.3.52-1-x86_64.pkg.tar.zst
pipewire-pulse-1:0.3.52-1-x86_64.pkg.tar.zst.sig
pipewire-pulse-1:0.3.52-2-x86_64.pkg.tar.zst
pipewire-pulse-1:0.3.52-2-x86_64.pkg.tar.zst.sig

Okay, I’ve got a couple to choose from, it looks like the x.52 packages were giving me problems, so I’ll try to downgrade to the x.51 versions and (fingers crossed) see if that issue goes away after a reboot or not.

sudo downgrade pipewire

##selected the x.51 version from my local var packages and auto added to pacman IgnorePkg list for now, repeat with other packages…

sudo downgrade gst-plugin-pipewire
sudo downgrade pipewire-alsa
sudo downgrade pipewire-jack
sudo downgrade pipewire-pulse

I’m sure there’s an easier way to do a downgrade, but this was my first experience doing it, and it wasn’t that bad! Sorry for the long post, I find I tend to learn a lot better and retain things a bit more when I write some of these things out. Might be common knowledge for some users here, but this was nonetheless very helpful for me to learn :slight_smile:

Now time to reboot and see how this bug is. Will update with an edit in a moment. . .

Thanks for the ‘somewhat lengthy’ report, it may indeed help someone, I think.

You got my fingers crossed!

1 Like

Omg that did it! Downgrading pipewire gst-plugin-pipewire pipewire-alsa pipewire-jack pipewire-pulse to version 1:0.3.51-1 fixes the issue I’m having of the audio jumping to 100% for a second before jumping back down to the normal volume. My ears can breathe(?) a sigh of relief now!

The only downside is the two most recent and latest versions of pipewire still have this issue. Oh man, this is gonna be a tricky bug report to file :sweat_smile:

2 Likes

do you have pipewire set to not suspend nodes? could be suspending the node then when its turned back on causes the volume issue.

1 Like

Would you mind expanding on that a little bit? I haven’t done or set anything in pipewire other that just installing it. How do I check or change for suspend nodes?

if using wireplumber you can configure it by copying the config files from usr/share to .config like this

cp -r /usr/share/wireplumber ~/.config/wireplumber

in the /home/“username”/.config/wireplumber/bluetooth.lua.d youll find 50-bluez-config.lua

in that file at the bottom will be

apply_properties = {
      --["node.nick"] = "My Node",
      --["priority.driver"] = 100,
      --["priority.session"] = 100,
      ["node.pause-on-idle"] = false,
      ["resample.quality"] = 5,
      ["channelmix.normalize"] = true,
      ["channelmix.mix-lfe"] = true,
      --["session.suspend-timeout-seconds"] = 5,  -- 0 disables suspend
      --["monitor.channel-volumes"] = false,

The section with [“node.pause-on-idle”] = false, will be commented out with - - in front of it, remove the - - and make sure node pause is set to false. You can do this for non BT nodes also with the file /.config/wireplumber/main.lua.d/50-alsa-config.lua in the same section at the bottom.

2 Likes

edited my previous post to fix the wrong file for BT config…whoops lol

1 Like

@Echoa Okay let me try updating pipewire again to the latest version and trying this out. Thanks for the suggestion, I’ll report back shortly. :+1:

2 Likes
~/.config/wireplumber/bluetooth.lua.d

apply_properties = {
      --["node.nick"] = "My Node",
      --["priority.driver"] = 100,
      --["priority.session"] = 100,
      ["node.pause-on-idle"] = false,
      --["resample.quality"] = 4,
      --["channelmix.normalize"] = false,
      --["channelmix.mix-lfe"] = false,
      --["session.suspend-timeout-seconds"] = 5,  -- 0 disables suspend
      --["monitor.channel-volumes"] = false,

I did what you said, and rebooted, and tested this on the vx.52-2 pipewire package, but sadly it did not fix it at all.