206
Pipewire vs PulseAudio: What's the Difference? (itsfoss.com)
submitted 8 months ago by petsoi@discuss.tchncs.de to c/linux@lemmy.ml
83 comments fedilink hide all child comments
top 50 comments
sorted by: hot top controversial new old
[-] TheGrandNagus@lemmy.world 99 points 8 months ago* (last edited 8 months ago)

PipeWire is great.

I remember a lot of people kicking up a fuss about it years ago saying it's a mess and we should stick to PulseAudio or routing audio to ALSA, but personally for me it's been great, far less troublesome than previous solutions, and the vast majority seem to agree.

The pain points were short-lived and now we're reaping the benefits of having a modernised, easier to maintain, less janky system. Credit to the devs, and to the distros who pushed it.

[-] AbidanYre@lemmy.world 32 points 8 months ago

There was a similar fuss when distros moved from alsa to pulse.

[-] SpaceCadet@feddit.nl 32 points 8 months ago

And rightly so. There's a reason we're migrating away from pulse to pipewire.

For the longest time the solution to any audio issues was "just uninstall PulseAudio, and use plain ALSA", and that usually worked. I held out for years and ran an ALSA only setup because it just worked and PulseAudio was always giving me one issue or another (audio lag, crackling, unexplained muting), until some applications started to drop ALSA support.

Then Pipewire came along, and so far it has been rock solid for me.

[-] folkrav@lemmy.ca 5 points 8 months ago

Both were just a pain in their own right, IMHO. My previous Focusrite interface was quite fiddly to get working with ALSA and just worked OOTB with Pulseaudio. I also don’t miss messing with ALSA/JACK at all.

Pipewire has pretty much been a drop-in replacement for me, with how it can act as a Pulseaudio backend.

[-] SpaceCadet@feddit.nl 3 points 8 months ago

Possibly hardware dependent?

I always had audio hardware that was well supported by ALSA, I never had any ALSA issues until applications stopped supporting it.

[-] Jordan_U@lemmy.ml 4 points 8 months ago* (last edited 8 months ago)

Pulseaudio used features of sound cards (most prominently the hardware read pointer) that ALSA/dmix alone never used.

ALSA/dmix could allow you to get the same power savings as pulseaudio if you set the hardware ring buffer size to, say, 2 seconds.

And that would be fine of you were just playing some music, but if you were also chatting and wanting to get prompt notification sounds they would always be delayed between 0 and 2 seconds depending on where the hardware read pointer happened to be when the system tried to play a notification sound.

ALSA/dmix could also allow you to set a tiny buffer size. Then your music would play, and your notification sounds would play promptly too. But if you were just playing music your CPU would never be able to go into the lower power sleep states because it would need to wake up every centisecond to service the tiny ring buffer.

That would kill your battery life.

Pulseaudio's (terribly named) "glitch free" audio feature was the first solution for Linux that allowed you to get power savings and low-ish latency. Your mp3 player filled up the ring buffer once every two seconds, and if a notification came in pulseaudio would look at where the hardware read pointer was, take the contents of the buffer that was just about to be read, and mix the notification sound into it, writing the newly mixed sound data to the buffer just before the sound card read it.

So, from the user's perspective nothing interesting seemed to happen, but they get better battery life and things like notifications or game sounds work like they expect them to.

ALSA drivers would commonly advertise support for accurately and precisely reporting the position of the hardware pointer, but since nothing actually used that info before, many drivers gave incorrect results, which would only cause problems when using pulseaudio.

load more comments (3 replies)
[-] WarmApplePieShrek@lemmy.dbzer0.com 2 points 8 months ago

until some applications started to drop ALSA support.

Just run them with apulse

load more comments (1 replies)
load more comments (1 replies)
[-] HuntressHimbo@lemm.ee 19 points 8 months ago

Having been a linux user around the time of both rollouts I've had a way better time with pipewire. We've come a long way since OG pulseaudio

[-] AbidanYre@lemmy.world 7 points 8 months ago

I seem to remember canonical rushing pulse into an LTS before it was actually ready. Not the first time they've done that either.

[-] GenderNeutralBro@lemmy.sdf.org 11 points 8 months ago

I remember a lot of people kicking up a fuss about it years ago saying it’s a mess

I remember the same type of discussion when PulseAudio was new, nearly 20 years ago. It's just growing pains. I hopped on board with PulseAudio ASAP back then, and yeah, it was kind of a mess but it did what I needed, and the alternatives did not.

I don't recall having any audio issues in recent years, either on PulseAudio OR PipeWire. But then again, I'm still not running Wayland (I plan to...soon™) and this is the first I've heard of issues with Flatpak (maybe I've been using PipeWire longer than I've been using Flatpak; can't recall).

load more comments (2 replies)
[-] umbrella@lemmy.ml 62 points 8 months ago* (last edited 8 months ago)

pipewire simply eliminated all the quirks from my use case.

the transition was annoying, but i don't even think about how bad linux audio used to be anymore.

wish the transition to wayland was going this well.

[-] Rustmilian@lemmy.world 7 points 8 months ago* (last edited 8 months ago)

With Wayland it was either break everything and improve, progress, and innovate over time with something actually maintainable & expandable,
Or... make x11\Xorg 2.0 and have to rewrite the entire stack yet again in only a few years.

[-] jaxxed@lemmy.world 12 points 8 months ago

And it was the X devs who made the choice.

[-] lengau@midwest.social 5 points 8 months ago

The transition for me was "install Pipewire and its pulseaudio compatibility package, remove pulseaudio, reboot."

There are a couple of quirks (updating Apparmor rules makes KDE think I've reattached all my audio devices), but it's mostly pretty smooth.

load more comments (1 replies)
[-] nintendiator@feddit.cl 56 points 8 months ago* (last edited 8 months ago)

Pipewire: works.

Pulseaudio: worksn't.

Really, it's as simple as that. Pulseaudio tried to be the systemd of sound and ~~failed~~ succeeded pretty horribly. Even its packaging was horrible, back when it was first put into Fedora and I tried uninstalling, it threatened taking down Libreoffice and Gedit with it.

[-] Theharpyeagle@lemmy.world 10 points 8 months ago

back when it was first put into Fedora and I tried uninstalling, it threatened taking down Libreoffice and Gedit with it.

I did this back when I was a newbie and somehow destroyed either the display server or some other part of the GUI. Sound issues have made me nervous ever since.

[-] Auzy@beehaw.org 8 points 8 months ago* (last edited 8 months ago)

Pulseaudio is NOT a failure lol

ALSA, Esound, OSS etc were always conflicting pre-pulseaudio. Sometimes you'd get sound, you'd always have to screw around with the sound server settings in different apps between KDE and Gnome apps, and gaming was a disaster. Even just using XMMS2 was a pain with Netscape/Firefox

It was a huge step forward, even with initial teething problems.

The only thing it didn't solve was low latency (for music production), and that's really the huge advantage of Pipewire. It did take a while to get there though..

In Xfree86 days, Linux wouldn't have had a future if PulseAudio wasn't released. It was one of those critical elements (along with Compiz, XrandR, DRI, Udev, PackageKit and Steam) which actually made Linux competitive against OSX and Windows at the time

load more comments (4 replies)
[-] I_like_turtles3@lemmy.world 4 points 8 months ago

Pipewire: works.

Does it have jack support? I have a network sound server and I use both linux and windows clients. I solved windows clients with the jack plugin.

[-] Piece_Maker@feddit.uk 8 points 8 months ago

Pipewire's got fantastic JACK support. You can even run standard JACK control GUI's like Carla on top of it and expect them to work just like they would on regular JACK

[-] I_like_turtles3@lemmy.world 3 points 8 months ago

Can I authenticate clients with the cookie thing?

[-] SolidTux@lemmy.ml 3 points 8 months ago

I do still have some problems with freewheeling. Ardour always crashes on exports when using the Jack interface, but everything works over the Pulseaudio interface. It might be an Ardour thing, but it doesn't occur when actually running Jack. So something is actually different with Pipewire.

[-] sugartits@lemmy.world 4 points 8 months ago

Well that's just poor packaging.

load more comments (1 replies)
[-] WarmApplePieShrek@lemmy.dbzer0.com 3 points 8 months ago

IIRC wasn't Pulseaudio and systemd made by the same person?

load more comments (3 replies)
[-] excitingburp@lemmy.world 38 points 8 months ago

PipeWire wins in the feature-set game, which is why it is being preferred over PulseAudio.

According to the inventor of PipeWire, this is the wrong perspective to take. PipeWire is preferred over PulseAudio as a server, clients (apps) should continue to use the PulseAudio/JACK APIs because the PipeWire API is not designed for general use (it's designed for things like pipewire-pulse and pipewire-jack).

[-] SpaceCadet@feddit.nl 20 points 8 months ago

clients (apps) should continue to use the PulseAudio/JACK APIs because the PipeWire API is not designed for general use

Really? That is news to me ... explains why mpv's pipewire audio output was briefly broken a couple of months ago.

[-] excitingburp@lemmy.world 14 points 8 months ago

I heard it in a podcast, but here's a written source on that: https://fedoramagazine.org/pipewire-1-0-an-interview-with-pipewire-creator-wim-taymans/

The message is still to use the PulseAudio and JACK APIs. They are proven and they work and they are fully supported.

I know some projects now use the pw-stream API directly. There are some advantages for using this API such as being lower latency than the PulseAudio API and having more features than the JACK API. The problem is that I came to realize that the stream API (and filter API) are not the ultimate APIs. I want to move to a combination of the stream and filter API for the future.

[-] LainTrain@lemmy.dbzer0.com 4 points 8 months ago

So the middleware stays the same but the underlying server changes? That's an amazing strategy I wish Wayland did this instead of breaking damn near everything with it's strange restrictions on behavior and overlays

[-] NekkoDroid@programming.dev 34 points 8 months ago* (last edited 8 months ago)

The thing with Wayland and X11 is: this couldn't really be done because of how fundamentally ~~broken~~ incompatible X11 is (and there is XWayland for most clients that mostly works)

[-] lengau@midwest.social 9 points 8 months ago

That's what xwayland is.

Apps can talk to xwayland with the x11 protocol but instead of an X server rendering it, your Wayland compositor renders it.

The restrictions come from the fact that those x11 behaviours are exactly things the industry has decided are a bad idea and should be replaced.

load more comments (16 replies)
[-] ray@lemmy.ml 8 points 8 months ago

Yeah it's kinda the opposite of "New interface, old implementation."

Which I learned from https://henrikwarne.com/2024/01/10/tidy-first/

[-] ProtonBadger@kbin.social 3 points 8 months ago

But it was the X protocol that needed to be replaced.

[-] LainTrain@lemmy.dbzer0.com 2 points 8 months ago* (last edited 8 months ago)

And it hasn't done that because no one is going to replace it a good but old pipe with a few issues with a pipe with a massive hole in it "by design"

load more comments (4 replies)
[-] Snarwin@kbin.social 24 points 8 months ago

As someone who occasionally dabbles in music production on Linux, I love that Pipewire lets me run JACK and Pulseaudio apps side-by-side without having to jump through hoops.

[-] OneRedFox@beehaw.org 19 points 8 months ago

Pipewire was honestly the most pain-free introduction of a new audio technology on Linux; it was a nice change of pace.

load more comments (1 replies)
[-] Diplomjodler@feddit.de 8 points 8 months ago

I always had trouble with the sound on video calls with PulseAudio. Since I've switched to Pipewire, everything has been smooth.

[-] Baggie@lemmy.zip 8 points 8 months ago

Would love to use it, it has the incorrect channel map for my surround sound system which apparently cannot be changed like it can in pulse? After that gets sorted then sure.

[-] mactan@lemmy.ml 6 points 8 months ago

my system sets the wrong bitrate for a device but I was able to configure it, you may want to browse the wireplumber wiki and see if its config options can meet your use case

[-] Baggie@lemmy.zip 4 points 8 months ago

That's a good tip, it probably can but I'll need a bit of learning to figure it out. The Linux audio situation is a hell of a learning curve sometimes.

[-] electricprism@lemmy.ml 8 points 8 months ago

I miss the pulseaudio restart command.

Sometimes my 3.5mm aux isn't detected in pipewire until I reboot.

pulseaudio -r used to do the trick iirc

[-] Snarwin@kbin.social 24 points 8 months ago

On my distro (debian) I can use systemctl --user restart pipewire.service.

[-] verdigris@lemmy.ml 7 points 8 months ago

This is just generally how you should restart most things on systemd systems.

[-] electricprism@lemmy.ml 6 points 8 months ago

Thank you, I added the command to my Linux Journal,

Your post motivated me to do some more trials and it ended up that my greetd greeter was locking up the audio sink.

So I made sure to add a command after the greeter exits killall -u greeter and the sink finally passed correctly to the logged in user just fine after that.

In reviewing the arch wiki some more too I've installed wire plumber session manager for pipewire, I am still a little confused about it's function and relation to pipewire but maybe that has helped too?

Cheers :)

[-] burrito@sh.itjust.works 3 points 8 months ago

I used to have to occasionally run this but I'd say it has been at least a couple of years since I last had to. I was a pretty early adopter of pipewire because it solved some Bluetooth issues that pulseaudio had. It has improved immensely since I first started using it.

[-] electricprism@lemmy.ml 2 points 8 months ago* (last edited 8 months ago)

To be fair (with pipewire*) my audio issues usually related to HDMI audio output which has been a PITA for like 20 years since the days of Xbox 360.

I started using PipeWire as soon as Arch switched the recommended default and I agree, it cleared up a lot of issues and fixed my Bluetooth headset, which was nice.

My 3.5mm issues are complicated by the scenario where I have a extension cable always plugged in but not always my headphone cable (sennheisers stock cables aren't super long)

I just wanted to add this as a "to be fair" and there is a element of "user error" where I just haven't put enough time in to really learn pipewire.

Well last night I resolved my problems by making sure to kill all processed owned by the greeter (as seen in my other post thanks to OP^^)

`killall -u greeter'

Now I can enjoy my Ubuntu startup sound in peace /s /volume-warning

https://yewtu.be/watch?v=CQaEXZ-df6Y

load more comments (1 replies)
load more comments
view more: next ›
this post was submitted on 23 Feb 2024
206 points (97.7% liked)

Linux

48214 readers
743 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz