Fedora 34 Gets Sign-Off For Trying To Default To PipeWire For Audio Needs

[cl333r]

If other distros refuse to adopt PipeWire Red Hat could integrate it into systemd.

[You-]

This is going to suck, I just know it. Switching to PipeWire with no transitional phase leaves no time to fix any of the issues you tend to only find when there's a significant rollout.

and with that mindset, it will always suck. because you wouldnt even roll it out on the development release with the ability to roll back if it is found to suck because no significant deployment is ever allowed because "it might suck".

[You-]

If other distros refuse to adopt PipeWire Red Hat could integrate it into systemd.

They most probably already use it (for screen sharing).

But we get into a strange situation here when we are migrating from sofware written Lennart Pottering. Should the haters hate the software that was originally authored by him, or the change away from it? choices choices.

[boxie]

Acorrding to their wiki and commit history. They are ".. using the exact same pulseaudio code and config files to set up devices and mixers, ports and jack detection. There should not be any difference between PipeWire and PulseAudio on how devices are detected and controlled."

Thank you for RTFM'ing for me

This is actually quite exciting!

[Azpegath]

Great news, I hope they are able to dedicate the needed resources to fixing the instabilities they unearth when a broader user base starts using it. They must "take a chance" (as ABBA put it) at some point. I wish that more distributions had done that with regards to Wayland, to softly force a quicker adoption. I prefer robust Wayland support over most of the other "new functionality" that has been released as part of DEs in the last 5 years.

[rene]

I recently tested it and while it worked somewhat as a drop in replacement, the experience was not exactly trouble free: https://www.youtube.com/watch?v=2U9Qq9h4FFo IMHO this reinventing the wheel every decade in audio, video, graphic stack is exactly why there is not a year of the Linux desktop.

[Britoid]

The issue I have, is there are still no clear step-by-step instructions on how to test the latest pipewire on F33.

I have done some testing, and reported issues months ago, when testing pipewire was just a matter of creating some symlinks. But now there are actual package conflicts, and a simple "dnf swap" does not take care of them.

e.g.

sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing
Last metadata expiration check: 1:20:27 ago on Mon 14 Dec 2020 06:57:53 CET.
Error:
Problem: The operation would result in removing the following protected packages: gnome-shell
(try to add '--skip-broken' to skip uninstallable packages)

This issue has existed for weeks, and the upstream developers are aware of the issue but have not provided a solution.

read the instructions at https://copr.fedorainfracloud.org/co...ewire-nightly/

[Mez']

Great news, I hope they are able to dedicate the needed resources to fixing the instabilities they unearth when a broader user base starts using it. They must "take a chance" (as ABBA put it) at some point. I wish that more distributions had done that with regards to Wayland, to softly force a quicker adoption. I prefer robust Wayland support over most of the other "new functionality" that has been released as part of DEs in the last 5 years.

I'd much rather have people like you adopting early and thus alpha/beta testing than forcing (softly is a way to put it, but it's still forcing) buggy disruptive stuff. For normal users who don't want to tinker to solve wayland issues, let it deserve its prime time and climb each step of the ladder in due time.
I've had to deal with and to spend time solving a lot of graphics issue between 2005 and 2012, and I'm not going to go back 10 years to an unstable system just because some believers with limited workflows want to force it on everyone.

[brent]

and with that mindset, it will always suck. because you wouldnt even roll it out on the development release with the ability to roll back if it is found to suck because no significant deployment is ever allowed because "it might suck".

That's not true. In an earlier thread, I suggested a transition in several steps. For instance:

Fedora 34: ship both PulseAudio and PipeWire, set PulseAudio as default, but allow easy switching. Ask users to test it and report bugs, repeatedly. I know I would give it a try under these circumstances, as would many others.
Fedora 35: switch to PipeWire as default, buw allow users to easily switch back to PulseAudio
Fedora 36/37: drop PulseAudio fallback after most known PipeWire issues have been fixed

While Fedora 33 in theory ships an option to switch to PipeWire for testing, it doesn't work (as outlined in this thread) and there's no official call for testing or the like either. It's still a bit too early for this anyway. The suggestion to just use a bleeding-edge COPR with nightly builds of PipeWire is funny. If there's anything that shows that PipeWire is not ready for primetime, it is something like that.

Switching out a vital system component (for desktop users anyway) with little to no systematic testing is like throwing shit on a wall and seeing what sticks. It's simply not good engineering.

[JackLilhammers]

This is going to suck, I just know it. Switching to PipeWire with no transitional phase leaves no time to fix any of the issues you tend to only find when there's a significant rollout. It's nice that PipeWire works for a few developers and early adopters, but that doesn't tell much about the user base at large. And the issue Rob72 points out that developers just don't appear to care all that much... sigh.

Besides, wasn't PipeWire still severly lacking in some areas, like Bluetooth support?

Well, pushing new stuff in Fedora is kind of RedHat's way of doing a significant rollout for RHEL