Using Pipewire? Notice any sound, quality improvement?

Linux/FOSS Questions
41

There are 3 things

  • the original creative idea of the person who composed a piece of music
  • the performance … all the energy added by the musicians
  • the audience… including the power of the long term impression which persists after the performance is over.

It is the third thing which is the real spirit of music… the part that lives forever

42

Beethoven never ever heard his 9th symphony. It sounded for him only in his mind: he was totally deaf that time…

+10000!

I do love the D minor Toccata and fugue of J.S. Bach.
There are only 2 men who could play it 100% for my taste: Edward Power Biggs (british), and Gabor Lehotka (hungarian). All other implementations I heard so far were so weak compared to their performances.

I can cite here Bert Kaempfert, totally agreeing with him:

“I want to make music for everyone. It’s meant to give people pleasure.
If it doesn’t, it’s failed in its purpose.” (Bert Kaempfert)

All of the wisdoms we are talking about here are discovered already :wink:

43

Yes, certainly.
They apply to books, and drama too . … all creative activity
has this 3-fold structure.

44

too bad you couldn’t opt out and just use pulse for another 5 years until they fix it.

45

Yeah, these things can take time.
Audio seems to be a raft of problems.

46

So, an extended-delay update on this part of my PipeWire woes. On the suggestion of one of the (devs? power-users? honestly not sure) at that bug I linked to… well, I’ll just copy the update I posted there.

An even stronger work around may be to set ["api.alsa.soft-mixer"] = true for the affected device, which will force the use of software volume control.

THAT change, OTOH, was completely effective in making the volume curve cover the entire range of the mixer scale. I expected there to be some sort of downside, like increased CPU consumption or audio quality being more easily affected when the system was resource-constrained, but so far I have to confess that I haven’t noticed anything of the sort.

Initially I made the change in my user configuration, and I was having troubles with reduced volume — I’d set the hardware volume to 100% and everything would be fine at first, but it seemed like the system was reducing it when the mixer wasn’t under the control of my user session. So I moved this configuration to /etc/wireplumber/main.lua.d/99-alsa-volumes.lua:

table.insert (alsa_monitor.rules, {
    matches = {
      {
        { "device.name", 
          "matches", 
          "alsa_card.usb-VIA_Technologies_Inc._USB_Audio_Device-00" 
        },
      },
    },
    apply_properties = {
      -- ["api.alsa.ignore-db"] = true,
      ["api.alsa.soft-mixer"] = true,
    }
})

…And did a sudo alsactl store 2 with that card’s hardware volume set to 100%, and since then I haven’t had any further issues.

So, I’m still stuck with analog audio, but at least the volume range is sane.

47

Hi Frank Dana,
Thanks for the feedback and for sharing your post on Pipewire.

Congrats on your tireless research to solve your audio problem

Jorge

48

I noticed something disturbing the other day…

I’m building out two RHEL9 servers for a customer…

They wanted OpenJDK for the application they’re going to deploy…

And this :

dnf install java-1.8.0-openjdk

Installed a mountain of JUNK that won’t ever be used, like a bunch of icons and some stuff for X - and : pipewire! WTF? Really - on a headless server running as a VM in VMware ESX?

Why would the Java “metapackage” require Pipewire? What use would it be on a headless server?

[root@SERVERNAME ~]# dnf list installed |grep pipewire
pipewire.x86_64                                1.0.1-1.el9                      @rhel-9-for-x86_64-appstream-rpms
pipewire-alsa.x86_64                           1.0.1-1.el9                      @rhel-9-for-x86_64-appstream-rpms
pipewire-jack-audio-connection-kit.x86_64      1.0.1-1.el9                      @rhel-9-for-x86_64-appstream-rpms
pipewire-jack-audio-connection-kit-libs.x86_64 1.0.1-1.el9                      @rhel-9-for-x86_64-appstream-rpms
pipewire-libs.x86_64                           1.0.1-1.el9                      @rhel-9-for-x86_64-appstream-rpms
pipewire-pulseaudio.x86_64                     1.0.1-1.el9                      @rhel-9-for-x86_64-appstream-rpms
49

Seen that before in Gentoo.
Some calculation package, I think it was Octave, required pulseaudio and initiated a whole chain of dependencies. All it wanted to do was make a beep… so it installed a whole soundsystem!

50

“previously” I mostly used to use Bluetooth audio from my Pop!_OS 22.04 desktop machine - but last ~2-3 months I’m mostly jacked into the 3.5 mm headphone / speaker jack on the motherboard - same set of headphones (i.e. they’re Bluetooth but also have 3.5 mm input jack - Sennheiser LE-HD 458BT).

Today was listening to some music, and it kept “popping” and stopping (the sound - not the track) using Sayonara… Annoying as hell - as you (me anyway) want the music for relaxation - but glitching music is the reverse of relaxing.

Looked up (googled) :
“pop!_OS music keeps glitching”

And ended up here :
https://www.reddit.com/r/pop_os/comments/ph6lcc/glitchy_audio_issue/
which took me here :

I did this :
systemctl --user restart wireplumber pipewire pipewire-pulse
then :
rm -r ~/.config/pulse

But that didn’t fix it… So I did this instead :

systemctl --user stop wireplumber pipewire pipewire-pulse
rm -r ~/.config/pulse
systemctl --user start wireplumber pipewire pipewire-pulse

Restarted Sayonara - and the issue has gone away (for the time being).
I guess I know what to do next time… Don’t remember this happening several iterations ago when it was just Pulse, or Alsa…