Pipewire to replace Pulseaudion on Ubuntu 22.10
discourse.ubuntu.com
discourse.ubuntu.com
My switch to Manjaro has only left me with one annoyance and that's that it doesn't remember the default sink for some reason. So far the 2 second clicks haven't been annoying enough for me to invest time into fixing that, but one day I'll probably find that darn broken setting...
I also don't like how you have to compile your own AUR frontend. You would think that would be pre-included, since it seems to be one of the star attractions of Arch.
I wasn't a fan of how long it takes to compile things. I also remember having to figure out dependencies manually, it doesn't just do it all for you like apt/dpkg.
I don't fully trust it any more than random AppImages from GitHub releases, to be honest, since I've heard there has been malware in the past, and compiling yourself gives zero protection.
Unless you are going to read through tens of thousands to millions of lines of code, you're still just trusting whoever put the package up there, and hoping you would have heard about it if there was a virus. I suspect not nearly as many people go around randomly reviewing code as some might like to think.
It does work, and I can see the value if you want to use things that for whatever reason aren't in Debian.
I actually kind of like the curation effect that Debian has though. If it's in the repos, it gives you a clue about what is popular enough that someone bothered maintaining it. If it's not in Debian and Fedora, it's probably more experimental than I'd like it to be.
Why would I want per-app volume? Pretty sure all relevant apps have a setting for that.
> headphone jack detection
What do you mean by this? My headphone jack works just fine with just ALSA and no configuration.
> probably 5 other things I use daily but don't know about
Doubt.
This actually sounds like something that might make me switch to Pipewire one day.
The rest of your comment seems to indicate to me that you have some kind of professional audio setup? Or is it something that might be interesting for the rest of us, too?
Yes, but that's not related to the comment. I tried to avoid my fancy use cases. It's more that through this I know that pipewire makes some scenarios trivial that people normally wouldn't know how to achieve or would spend lots of money on (https://rogueamoeba.com/loopback/ for $100+)
The rest is just basic usage. For example, I'm in a video call and want to add just the browser's sound output to the call, but still hear it myself. With pipewire, that's "open (your preferred audio graph tool)", "drag and drop from browser to zoom". Runtime change, multiple sinks, including app sink.
Did they realize they needed a better solution? (though Pipewire also deals with video)
(the point here is basically: why couldn't they fix pulseaudio?)
* low latency / pro audio
* secure video streaming and desktop capture under Wayland
* unification of Jack and PulseAudio ecosystems (Pipewire implements both APIs)
Probably.
But the Pipewire developer is at Red Hat, and Fedora has it as default.
I don't think RedHat or anyone ever said that Pulseaudio is perfect or covers all use cases.
Personally I think the Linux world follows redhat way too closely. Especially since it's really IBM now.
But I'm more open to pipewire because of this. Having nice people behind it is important too IMO.
Personally I don't really trust either and I lament the high level of commercial involvement in Linux. It's one of the reasons I use FreeBSD. And they are still doing very well in features. For example they had jails (real containers, not chroot) way before Linux had containers.
I don't believe in "win-win scenarios" when it comes to commercialisation. In the end the commercial interests will always trump everything. I think RedHat's recent actions around CentOS are a good example of that.
I'm pretty sure he got similar amounts of criticism at the time
Pipewire is a completely new backend written from the ground up keeping interactive use cases in mind. It implements the Pulseaudio API for compatibility, so it can be used as a drop-in replacement, but has its own extensible interface.
Because that worked out so well for Mir and Upstart, right?
AFAIK this version of Pop!_OS is using pipewire, so I wonder if there's still more work to be done?
https://lwn.net/Articles/847412/
https://www.collabora.com/news-and-blog/blog/2022/03/08/pipe...
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ
Arch tried to switch off from `pipewire-media-session`, because it's merely a proof of concept whose development is dead, but found that WirePlumber simply isn't ready yet (https://archlinux.org/news/undone-replacement-of-pipewire-me...).
It seems like, unless and until WirePlumber is actually ready, PipeWire isn't quite ready?
It's irrelevant for those who've picked pipewire as audio server specifically, so it will most likely be irrelevant for Ubuntu.
Plus the Ubuntu 22.10 release is in October 22 (they use calendar versioning), so there's still some time to work out the kinks.
From my perspective, 22.04 is no better or worse than previous releases. I've always had Bluetooth audio issues with Linux. And I'm usually outputting audio to the laptop speakers or to HDMI, which have worked just fine.
That said, it is a drop-in replacement, so pretty unnoticeable for most purposes. So if you notice nothing at all, that means success.
If you knowingly corrupt data, then what else matters?
(Having "we recommend that people who use ZFS don't upgrade" hidden in release notes doesn't negate it)