Pulseaudio had to contend with a huge number of buggy drivers, adapters, and clients. The bugs very gradually got fixed under pressure from PA, with PA always blamed. (PA of course also had bugs that gradually got fixed.) PW benefits from the more sane operating environment PA enforced.

I always used to delete PA because I had no desire or need ever to have more than one audio source feeding more than one audio sink. We don't live in a world compatible with that model anymore.

From what I've read, PA did expose a lot of driver bugs, but this was mostly caused by it rewinding audio buffers [0], a driver feature that was not commonly used before PA. PW doesn't use rewinding though.

[0] https://www.freedesktop.org/wiki/Software/PulseAudio/Documen...

Going to be very real, I do not really have more than an inkling of the "world" PW inherits or whatever, but this sounds like "trust us, this time it's okay." I might need a little more convincing this isn't just another attempt to recreate a "universal framework that covers everyone's use cases." (I won't like the obvious reference)

That notion might seem plausible, but the author of Pipewire witnessed the entire PulseAudio process, so has strong motivation not to repeat its reception, and plenty of hindsight to help.

Notably, the developer of Jack, the universally admired professional audio system, now uses PipeWire via its Jack-compatible API. He is frequently here on HN.

> I might need a little more convincing

What about you give it a try instead?

You should read up on what PipeWire is before you talk trash about it and start implicating it in some catastrophic repeat of PulseAudio that you just made up.

Nice of you to dismiss people’s (mostly a single one’s) free work.

I am not dismissing anyone's work. By this logic, the pipewire folks are dismissing ALSA and pulseaudio's work, which is equally absurd.

> the pipewire folks are dismissing ALSA and pulseaudio's work

That is just not true. PW uses ALSA for physical output and it implements PA so that all the apps just work. There is nothing dismissive about that.

Pipewire implements the APIs of Pulse, Alsa, and Jack. So instead of having to juggle between them all, you just have one service to manage and it all just works.

It only took a few lines for me to switch and I've never had a Linux audio issue ever since! (And when I have, it's been my fault like my volume was turned down or my speakers were unplugged lol)

How did you switch? I'd be interested in trying this on Ubuntu.

I made the switch this morning by following this: https://ubuntuhandbook.org/index.php/2022/04/pipewire-replac...

So far the only anecdotes I have are (a) everything seems to be working and (b) don't forget to reboot after installation.

Ah, thanks!

Should be pretty close -

https://wiki.debian.org/PipeWire

Apparently this is already running on my Ubuntu 21.10, I wonder if they switched over from the default. I've had no problems with BT at all, it just works. I wonder if that's why.

Thanks!

It's fine when it works. It's a monstrosity when it doesn't.

I spent an hour the other day trying to figure out how to tell it not to output audio through my DualSense controller haptics (which look like a four-channel audio output) when I connect it to an Intel NUC over USB. I never did succeed, and all the posts I found were basically other people asking how to do similar things.

I used pavucontrol to simply tell it to not do it. Once is enough.

In the sound cards list, just set to disabled.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound.

For a headless system, it's useless.

`pactl` is the command line version

Also tried, also useless. The program producing the sound is being run by another user.

And 'ssh -X' is also a thing.

>For a headless system, it's useless.

DualSense is a game controller. In this context, headless is unlikely.

Depends on how you define headless, but the fact is, I'm rarely logged into it, and there's no mouse nor keyboard connected, nor any X server running.

you can actually use pavucontrol for remote PA servers that have native-protocol-tcp running

$ PULSE_SERVER=192.168.1.21 pavucontrol

Very much. It's more like Jack all over again, but more friendly - than pulseaudio.

While not perfect yet (it's still a relatively young project) it works as good or better than pulse in most general usage scenarios and avoids a lot of nonsense that you used to have to go through with using jack audio in tandem with pulse as well.

For the most part it works out of the box with good latency without extra configuration and provides good routing options as well for more advanced usage.

Pipewire is able to handle LDAC on my Bluetooth headset and switch to mSBC to behave as a headset and use the headset as a wireless input device. It's awesome! Never had instability or glitches, even when you make complex audio changes and can almost feel the gears grinding. It hasn't let me down!