Now that Pipewire is pretty well a thing…
Anyone notice significant improvement on sound output or quality?
3 Likes
I notice stuff breaking when I try to use Pipewire, so I stay clear of it. lol
1 Like
It’s hard to say… I’m running pipewire on both my Pop!_OS 22 Ryzen desktop, and my Ubuntu 23.04 Ryzen Thinkpad…
All I can say, is the Pop!_OS audio experience, with the same device on Bluetooh (Sennheiser LE-HD 458BT - BTW - I really recommend this headset - mostly plug and play once you’ve got stable BlueTooth on Linux - I have them paired to 2 MacBooks, both my Linux machines, and my phone, and I can disconnect, and re-connect to any of them - “on the fly”) is much better than on Ubuntu 23.04 Thinkpad… and I don’t know if that’s hardware or software…
Pop!_OS Ryzen 7 Desktop pactl output :
Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 3787
Tile Size: 65472
User Name: x
Host Name: titan
Server Name: PulseAudio (on PipeWire 0.3.71)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_31_00.4.analog-stereo
Default Source: alsa_input.usb-045e_USB_camera-01.mono-fallback
Cookie: 6cd4:fd51
Ubuntu 23.04 (Ryzen 5 Thinkpad) pactl output :
Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 661
Tile Size: 65472
User Name: x
Host Name: fenriz
Server Name: PulseAudio (on PipeWire 0.3.65)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_05_00.6.analog-stereo
Default Source: alsa_input.pci-0000_05_00.6.analog-stereo
Cookie: 9c43:6d45
In both cases, PulseAudio is running on PipeWire. It’s also the same deal when I use a 3.5 mm jack / cable on those Sennheiser headphones, better sound from the desktop machine running Pop! (vs Ubuntu 23.4 on a Ryzen 5 thinkpad)…
2 Likes
Wish i had those headsets!
Logitechs are fine for me for now.
Maybe Senns as b’day gift in Sept.?
Now that’s an idea!
Brief tests on KDE Neon and MX 23b2 seem to prove a more stabilized sound.
Nothing near to FX Sound on Windows tho.
One thing I have noticed about pipewire - it’s running whether I need it or not! On my Pi Zero 2W under my user account - maybe 'cause I installed a minimal X on there it thinks I want sound… I NEVER run X on it (I think I install olwm) - so I don’t need pipewire (and wasn’t planning on using sound on it just yet anyway) - but I’m stumped if I can figure out which systemd service is starting it up!
OK - it’s pipewire.service (for some reason ZSH completion wasn’t finding it)…
Stopped that and resilio sync on the Pi Zero 2W
systemctl --user stop pipewire
systemctl --user stop pipewire.socket
systemctl --user stop pipewire-pulse
systemctl --user stop pipewire-pulse.socket
systemctl --user stop resiliosync.service
and it looks a truckload healthier :
x@albiorix ~ free -h
total used free shared buff/cache available
Mem: 474Mi 120Mi 290Mi 4.0Ki 126Mi 353Mi
Swap: 303Mi 28Mi 275Mi
A shame I can’t reduce that shared video memory (I’ve set it to “2”, but seems to be using 26+12 for “other stuff” - i.e. I don’t have 512 Mi total).
I kinda need resilio Sync though - I’m going to tune what I sync, and maybe run it on demand or something…
Still in two minds - I might set systemd to disable those pipewire services… I can run them manually if and when I need them…
I was sync’ing about ~200 GB to it via Resilio Sync - turns out the more you try to keep sync’d the more RAM it uses - so now I only sync my small share with mostly shell scripts…
I now have two scripts I run :
- stop pipewire and resiliosync, or just stop resiliosync, or just start resiliosync
- use rsync to update my two big shares (one is documents and images, the other is Music) on it on demand (i.e. when I decide to do it).
First script :
#!/usr/bin/env bash
# for the pi gadget - keep it low...
# Stop/Start PipeWire and/or ResilioSync
PROG=$(basename $0)
if [ $# -lt 1 ] ; then
echo "need to say on or off or start or stop..."
echo "or on >1< (to just do rsl) or >2< to do pipewire to... e.g.:"
echo -e "\t $PROG on 1 "
echo -e "\t will start just resilio sync..."
echo "exiting doing nothing..."
fi
ARG1=$1
ARG2=$2
case $ARG2 in
1)
export SVCSLIST="resilio-sync.service"
;;
2)
export SVCSLIST="pipewire pipewire.socket pipewire-pulse pipewire-pulse.sock resilio-sync.service"
;;
*)
echo "expecting 1, to just do RSL, 2 to do that and everything else..."
echo "exiting...."
exit 1
;;
esac
case $ARG1 in
on|On|ON|sta|start)
systemctl --user start "$SVCSLIST"
;;
of|Of|off|Off|OFF|sto|stop)
systemctl --user stop "$SVCSLIST"
echo "3" | sudo tee /proc/sys/vm/drop_caches
;;
*)
echo "wrong... wrong... feck orf!"
;;
esac
Second script :
#!/usr/bin/env bash
# Copy some stuff to the Pi "Gadget"
# We're only gonna do this if albiorix is on ethernet LAN (via Samsung Micro USB ethernet dongle)...
PROG=$(basename $0)
TOBOX="10.1.1.65"
PARENT="$HOME/ResilioSync"
FLDRS="$PARENT/bigshit $PARENT/Music"
do_it () {
for DIR in $FLDRS
do
rsync -av --delete $DIR/. $TOBOX:$DIR/.
done
}
if [ ! -f /usr/bin/fping ] ; then
echo "fping's not installed... maybe sudo apt install fping???"
exit 1
fi
fping -c1 -t300 $TOBOX 2>/dev/null 1>/dev/null
if [ "$?" = 0 ]
then
echo "Trying to sync $TOBOX over main LAN address..."
do_it
else
echo "LAN ethernet not connectd?"
echo "Probably not Sumsang'd in to LAN... exiting..."
exit 1
fi
I might actually revise it to skip the check if on LAN bit - it’s only the “delta” I need to sync, and that should be fine over WiFi…
Hi everyone,
glad to be back on the forum.
@danielson, I’ll tell you my experience with PipeWire.
My PC is old and I was having audio problems, for example, with Ardour or Tracktion Waveform and Jack at 44.1KHz or 48KHz: even increasing the buffer, for example to 1024 frames, I had many errors (xruns).
I switched about 2 weeks ago to PipeWire and the system is much more stable and I can use PipeWire at 48KHz with 256 frames without errors.
Regarding the sound quality: it is hard for me to say if it is better.
I’m using Debian Testing to work with the audio programs.
In Linux Mint, which is my main distro, I still use PulseAudio.
Jorge
6 Likes
I’ve had the opposite experience, though it is unquestionably down to my (incredibly cheap) hardware configuration. So, don’t take this as an indictment of PipeWire in general, more as a caution that its support for bargain-basement hardware is less than ideal. And before I even start, let me say that I’m still using PipeWire exclusively (it’s the preinstalled audio layer for all recent Fedora releases), I’ve just had to make some sacrifices/adjustments.
First, some background
(This is relevant, but not essential, detail. Feel free to skip to the next section if you’re not really interested in my computer’s life story.)
Back when I bought my current (used, ca. 2011 system acquired in 2020) desktop PC, I knew that it was a business-class machine, likely an office salvage/refurb. With that comes the certainty that its built-in video and audio support will be the absolute most bare-bones hardware it’s possible to solder onto a motherboard. So in the same order, I included the cheapest Nvidia PCIe GPU I could find (a GT 710 for $50) and a $20 USB audio interface from some Chinese manufacturer that had two things going for it: the price, and the fact that it features the same ‘combo mini-phono jack and optical audio output’ that Apple created(?) for the Airport Express.
Clever little design where the “bottom” of the headphone jack is actually an optical emitter, so with the right kind of fiber-optic cable you have an optical digital S/PDIF audio out. I also ordered said cable, since the Logitech speaker system on my computer desk has both optical and coax S/PDIF inputs.
The initial (PulseAudio) state of affairs
All this arrived, I set it up and installed the Fedora release at the time (I guess 33 or so), and lo and behold PulseAudio happily supported my USB audio interface (it’s some VIA chip, at its heart), including the optical digital out, meaning I could enjoy clear, hum-free 48kHz audio via the Logitech system. Only two channels even over S/PDIF, so no digital surround, but that wasn’t particularly surprising given the price and the fact that it’s a USB 2 device; bandwidth is not in abundance.
Then PipeWire came along, with its promise of a new, better take on all of the PulseAudio magic. (I’m an unashamed PulseAudio cheerleader: I know some people had their problems with it, but the first time I took the audio playing on my fileserver and rerouted it over the local network to the desktop computer’s speakers while it was playing, it felt like I was living in the freakin’ future, man! Turning on my paired Bluetooth headphones and being able to use pavucontrol to pick-and-choose, application-by-application, which audio is routed to them vs. which plays to the speakers, again live and in realtime, is similarly a glimpse of nerdvana.)
The PipeWire reality (in my situation)
Alas, that promise was not entirely realized.
The first thing I discovered was that the optical audio interface was now completely unusable. With PulseAudio it worked fine, but with PipeWire any attempts to play audio result only in a DEAFENING blast of white noise from the speakers. Clearly, PipeWire is not correctly encoding the audio data for the interface. After nearly blowing out my eardrums a few times trying to get this working (and pissing off my neighbors, since invariably the opportunities I had to fiddle with it came at 3, 4am), I resolved to give up on the optical out (the whole reason I bought the interface, remember), and just connect an analog cable.
That made the audio interface usable, but didn’t solve all the problems. It would still frequently go into static-mode (but not deafening, since the analog interface applies the software volume correctly even when fuzzed) at random times. I eventually discovered that I had to keep it plugged into a USB3 port (even though it’s not a USB3 device) in order to mostly-avoid the problem. Even still it occasionally happens, and I have unplug and re-plug the USB device so it resets and clears up. That may very well be the hardware’s “fault”, but it never, ever happened with PulseAudio.
Even when it’s working “correctly”, it’s not entirely correct. The USB mixer has a weird volume range of 0 - 45, corresponding (according to ALSA) to -45dB to 0dB. There’s a bug in PipeWire, still unsolved, where it maps the device to a software volume control with a range of -64dB to 0dB. The hardware mixer is synced to the decibel value of the software mixer, meaning that the audio cuts out when the software volume reaches ~19% (-45dB). The entire bottom 20% of the volume range is missing.
Conclusion
So, no, I wouldn’t say my PipeWire experience has given me better audio. I went from optical digital S/PDIF clarity to hum- and interference-prone analog, with an awkward volume range and occasional hardware crashes despite sacrificing one of my machine’s two USB3 ports to host its USB2 audio interface.
But if you use hardware that costs more than a decent lunch, on a system that wasn’t built 12 years ago, it’s probably a much better experience.
And the Bluetooth audio stuff does work just as well now as it did with PulseAudio; no complaints there.
2 Likes
@FeRDNYC, I agree with you. For me PipeWire still has a lot to evolve. My PC is also old, an AMD FX6300 CPU with a humble AMD Radeon R7 240 graphics card and I try to work with this hardware with audio programs.
One of the problems I was running into was latency. With Jack I had issues, but as I said in the previous post, I switched to PipeWire about 2 weeks ago and noticed a significant improvement. Of course, even if it is a small improvement, on an old PC this is very significant.
One of the problems I notice with PipeWire are the configurations I had and/or have to do and that have given me some work, because I’m still getting started with PipeWire and sometimes I don’t know if it’s a software problem, if it’s a “user” problem and, as I’m not using any distro with native PipeWire, for me, it’s a bit more complicated to get the system stable, because I’m also a Linux noob.
Sorry my question: I know you wrote “hum-free 48kHz audio via the Logitech system” but are you sure about the sample rate of the S/PDIF input of your Logitech? Have you tried PipeWire with 44.1KHz and 48KHz?
About “no digital surround”
I don’t know if it helps, but I found this information on how to get DTS via S/PDIF:
https://www.reddit.com/r/linuxaudio/comments/zc74dx/how_to_enable_51_surround_audio_via_spdif/
About USB2 port
Just a thought: have you tried disabling USB2 sleep?
I have a similar fault, but it was not solved by switching to USB3. The solution for me is to stop and start PipeWire. I had the same problem with Jack, but could never solve the problem.
1 Like
A more stable system is huge plus! 
1 Like
Already shared this on the thread I started but just in case, below is my experience:
I replaced the existing MX21 ahs with MX 23 ahs (officially released yesteday) and checked for audio/playback quality on both firefox and VLC (with the compression settings for movies). I must say I am impressed and (never thought I would write this about a Linux OS!) the quality is a rank ABOVE Windows – it is unbelievable!
Connected my moderate budget 2.1 system with this laptop (via both 3.5 mm wired and bluetooth) and this is the best audio quality–even without using any equalizers–I’ve ever heard on a Linux machine. Looks like MX team/volunteers did a thorough job on this one.
Bluetooth has no lag/latency whatsoever! The channel separation and clarity is unmatched! Just wow! I’m hearing notes/instruments I had never heard so clearly before.
So, in brief, yes - MASSIVE difference in the sound quality!
Quite sure, since I used it with PulseAudio for many months. The Logitech supports a range of sample rates; the USB interface supports only 48kHz (thankfully, 44.1kHz is a relic of the 1980s).
The issue, I suspect, is this:
The USB interface uses the s24le encoding, instead of the more common s32le like (among others) the motherboard’s built-in audio. That’s true for both the analog and digital interfaces. PipeWire apparently handles that OK (most of the time) for the analog interface, but completely hoses itself when faced with a digital interface in that format.
It’s already disabled. It’s a(n older, business) desktop, almost nothing sleeps by default. (The built-in audio interface did, and created a horrific hum every time it went offline, so I did have to add an options snd_hda_intel power_save=0 to /etc/modprobe.d/ to disable sleep mode, when I was using that interface.) I don’t let anything sleep (except the display) — I’m of the “People turn computers off?!?” persuasion. My systems are working busily even when I’m not sitting at the keyboard.
The fact that it crashes far less in a USB3 port than in the USB2 ports tell me that it’s a bandwidth issue: The interface is clearly very timing-sensitive, and if the link gets saturated or lags at all, it starts dropping samples and things get all out of whack. (Reinforced by the xruns logged in the system journal, when that happens.) The only surprise is that it can’t recover from that state without a manual hard reset. Even complete soft resets do nothing, it has to be yanked and reinserted.
I could enable passthrough digital audio (well, maybe, there’s no guarantee the interface is stable even for passthrough — but it probably is) and get surround from VLC, but that involves a number of sacrifices:
- It bypasses the software mixer, implying
- No software volume control (the Logitech has no remote, and its front-panel control knob is… “tetchy”, so having it be my only control over the intensity of the sound is less-than-ideal)
- Worse, no sound output from the rest of the system, because in passthrough mode VLC (or whatever’s sending AC-3 to the digital out) is directly routed to the output and has sole access to it.
I care about having digital surround less than I care about all of those things. And the built-in encoder (as my screenshot shows) is exclusively 2-channel, 48kHz, s24le.
1 Like
@FeRDNYC,
Thank you for your reply.
I’m sorry I’m only replying now, but I’ve been having health problems.
I never realized about differences in USB interface encoding. I’ll check what mine are to see if they match.
I hope you can find a solution for connecting the Logitech speakers by optical cable.
For my part, I will also look for more information to see if I can help you out.
Jorge
1 Like
The human ear generally a range of 20Hz-20KHz, no more. This becomes less when there’s hearing damage (quite easy to obtain these days).
So, how exactly would I hear the difference?
Yes, there’s the placebo and necebo effects. When I have sound on Linux, things are ok in my book.
1 Like
Hi @xahodo ,
This is a very complex question and I’m afraid I can’t answer it in a straightforward way.
I don’t know what you know about audio, so I would like to ask you, if you want, if you can do a test (it has nothing to do with what we are talking about pipewire):
Plug some headphones into your notebook and listen to a song. Now listen to the same song, but through the speakers of your notebook.
Do you notice any difference?
Jorge
Note to moderators: this is an off-topic. I don’t know if you want to move it to a new post.
EDIT: Please forget this post. we are talking by PM.
Sorry for the trouble caused
Hi @FeRDNYC,
First of all, I believe you know a lot more about PipeWire (and Linux too) than I do and I’m just trying to help you, so ignore this post if you don’t want help, which I totally understand.
If you doubt that it’s the audio format that is not compatible, because it is S24LE instead of S32LE, you can configure PipeWire to use the S24LE format.
My internal sound card uses S32LE, but I use an USB audio interface with the S16LE (16 bit) format.
I’ll mention the tests I did.
This is the info I have from pw-top before changing the PipeWire configuration:
As I didn’t have the folder ~/.config/wireplumbler/main.lua.d/, I created the respective folder, copied the file /usr/share/wireplumber/main.lua.d/50-alsa-config.lua to ~/.config/wireplumber/main.lua.d/50-alsa-config.lua and changed the owner of the copied file.
I edited the copied file, looked for the property “audio.format”, which was commented out --["audio.format"] = "S16LE",, I uncommented the property and changed it to S24LE ["audio.format"] = "S24LE",,I restarted pipewire and I got this info with the pw-top command:
In my case, if I have no audio program running, pw-top does not indicate any format:
NOTE: I believe that because my internal sound card and USB audio interface don’t accept the S24LE format, they aren’t on the pw-top list, but since your USB audio interface uses S24LE, you can, if you want, of course, do this test to find out if the fault is with the audio format.
Jorge
EDIT: I use Debian Testing with PipeWire and this morning I upgraded to 0.3.77.
I don’t know if the new versions can fix the problem with your USB Audio Interface.
2 Likes
Oh, I wouldn’t be so sure, particularly when it comes to PipeWire. I’ve banged my head against this a bunch, but not gotten very far with it, and most of what I “know” comes through experimentation, observation, and no small amount of assumption. (PW strikes me as very poorly documented, even compared to PulseAudio. Which is saying something. And tools like pw-cli and pw-mon spit out absolutely dizzying amounts of horribly-formatted information, to the point where I often still use pactl to examine the properties of the system, since its output is at least vaguely comprehensible.)
I hadn’t actually tried out pw-top, which does seem a far sight better than any of the other pw- tools, so thanks for that.
There’s also pw-config, which has very readable output, but even in the apparently-maximally-detailed pw-config -r list form there’s a conspicuous lack of anything remotely hardware-related in what it dumps out. But perhaps that has something to do with wireplumber being involved.
Your reply also inspired me to re-examine my system and refresh my memory about some of this stuff.
What I’d discovered (and subsequently forgotten) is that the ALSA interface actually doesn’t use S24_LE format, but rather S24_3LE — but according to this stackoverflow post that’s actually normal for USB audio. The difference, apparently, is that while S24_LE is a 32-bit aligned format with the top byte always filled with 0s, S24_3LE is a 24-bit aligned format with no “padding” byte.
PipeWire doesn’t appear to acknowledge that S24_3LE even exists. So I can’t tell if it’s actually using it, and what it calls S24LE is actually S24_3LE (since, as that post says, “There is no hardware that uses S24_LE.”) or if it really is using S24LE (as pw-top reports on my interface, without any configuration applied) and the interface is having to just discard the extra byte. If that’s the case, I suppose that could explain the xrun and interface-crashing issues, but we’re already in the land of heavy conjecture and wild guesswork.
While I do appreciate the help (honestly), and you have given me some interesting ideas to explore, I don’t know if I’m really going to do so. Some of the barriers are practical (I’m… not entirely sure where that optical cable I bought for the interface actually is anymore… I suppose it’s around here somewhere), and some are motivational — this is the primary audio output for my main “daily driver” PC, and right now I’ve got it in a state where it’s “working” (after a fashion)… screwing around with this stuff, in addition to the problems of horrible, loud noise bursts from the speakers, means that while I’m messing with it, I have no working sound from the machine.
If I had a separate system I could try it on (I do, my laptop) and a separate set of speakers that took an optical audio in (I don’t), I could temporarily switch to the built-in audio out on the desktop while I messed around with this interface on the laptop. But having to task my only set of speakers to the experimentation leaves me sound-less, which too quickly becomes a frustration that I can’t abide.
Fedora keeps up pretty well with the latest PipeWire releases; it looks like I’ve been running 0.3.77 since 2023-08-06, with a new build installed a week later on 08-12. But this has been going on since Fedora 35 or 36 (whenever they switched to PipeWire), and we’re now nearing the release of Fedora 39. Given that nothing’s changed with most of these issues in the past 2 years’ worth of 6-monthly distro updates, I’ve stopped expecting new releases will make any difference.
(I’ll get notified if the volume-scale bug is ever fixed, of course, but that seems unlikely as well. I don’t think any of the PW devs have even officially acknowledged that one as a bug. The unusable-digital-output issue isn’t even on their radar, AFAIK, since I’ve never reported it for lack of ability to supply testing/debugging info without, like I said, having to take down my machine’s entire ability to produce audio.)
1 Like
Chiming in again: yesterday, I loaded one of the community presets (LoudnessEqualization) for Easyeffects (on Pipewire) and tested some movies. The quality is impressive (specifically, the dialogues as compared to background score, sound FX); so good infact that I turned off the VLC compressor settings.
As mentioned before, even without the preset, the audio is best I’ve ever heard on a Linux machine and marginally beats Windows as well.
A lay user’s 2 pennies . . .
4 Likes
Have you ever tried FX Sound for Windows?
Yes, I didn’t find it to be of the same quality as Pipewire on Linux. Additionally, it screws up with the existing audio driver, even after you uninstall it (Realtek for my machine Win7 – which is doing pretty fine). Though you may have a different experience on your machine…?
For Pipewire, the default quality (without any enhancement such as EasyEffects) itself is very good. Used Easyeffects just to get rid of dramatic changes in sound level (low dialogues, loud explosions/background score). I now realized the full potentional of my hardware. I am using a popular domestic speakers brand, launched <3 years ago; can only imagine what it would be like with my older Audiotechnica headphones and Sony 2.1 setup.
Good to hear!
Oddly enough, found Pipewire to perform quite well on MX XFCE but not as good on its KDE iteration.
FX with old speakers outperformed any Linux distro i’ve tried thus far.
Just haven’t had the chance to test it yet with Pipewire.