Originally posted by ALRBP
View Post
Announcement
Collapse
No announcement yet.
Fedora 34 Gets Sign-Off For Trying To Default To PipeWire For Audio Needs
Collapse
X
-
- Likes 1
-
Originally posted by Rob72 View PostThe 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.
Code: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)
Code:sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing
Code:systemctl --user enable pipewire pipewire-pulseaudio
- Likes 1
Comment
-
Originally posted by You- View PostBut 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.
Comment
-
Originally posted by brent View PostFedora 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.
If they are to really launch it without a "easy to access for testing but not default"-step, they really need to make the change early on in the project and then put a lot of devs on it during development, so it becomes very stable.
My issue is with projects that do what you mention above, but instead of 34, 35, 36 for each step respectively, it's more like 34-48, 35-155, 155. For instance Wayland, which has been stable (the protocol) for a long time, but the porting to it by DEs/frameworks is taking a long time because it is not prioritized, "since nobody uses it yet". It's kind of the egg and chicken problem.
Originally posted by Mez' View PostI'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.
- Likes 2
Comment
-
Originally posted by finalzone View Post
Add the following
Code:sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing
Code:systemctl --user enable pipewire pipewire-pulseaudio
Comment
-
Switched to Pipewire on all my ArchLinux machines here, so far no problems but they all have simple audio setup.
Debian based distros still on PulseAudio/JACK as they have the more advanced audio setup.
Pipewire's compatibility layer with PulseAudio is great, no software seems to notice it was replaced.
Now need to try Unreal Tournament, as it had problems with PulseAudio, will it have problems with Pipewire ?
- Likes 2
Comment
-
Originally posted by nanonyme View Post
Looks like that removes alsa-plugins-pulseaudio which is completely incorrect. Just in case someone wants to try this out. This is broken and will result in any software using ALSA losing ability to talk to PulseAudio/PipeWire.
- Likes 1
Comment
Comment