Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by ALRBP View Post

    I can't answer for DEs but for programs, AFAIK PireWire provides PulseAudio compatibility and thus would work flawlessly with PulseAudio-only software (maybe with a few config tweaks).
    In some dream land maybe, yeah, but in practise software of this size and complexity will always have new bugs that will arise, and the compatibility layers will initially be insufficient. Plus PulseAudio does have support for pluggable modules which of course (?) wouldn't be available at all.

    Comment


    • #22
      Originally posted by Rob72 View Post
      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.
      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)
      Add the following

      Code:
      sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing
      to get the latest stable release of pipewire-pulseaudio which fixes the issue. You may need to manually enable pipewire-pulseaudio service via systemctl.
      Code:
      systemctl --user enable pipewire pipewire-pulseaudio

      Comment


      • #23
        Once again, I like to thanks the guin... , I mean, Fedora users for taking one for the team.

        Comment


        • #24
          Originally posted by You- View Post
          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.
          No, it is not strange. They are migrating away from software originally written by Lennart Poettering but no longer maintained by him. His last contribution was on Wed May 16 01:06:17 2012 +0200.

          Comment


          • #25
            Originally posted by brent View Post
            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.
            I agree, my impression was that it had been a user option to change to it during the last couple of releases. If the user had to re-install a whole new system, with for instance a nightly build, very few would actually run it.
            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 Post
            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.
            I agree, but perhaps don't use Fedora then? You have RHEL, or other more stable alternatives, that will eventuelly adopt PipeWire when it is stable and tested via the more unstable and bleeding-edge Fedora.

            Comment


            • #26
              it reduces the risk of delaying Fedora 34 Beta if such a revert is necessary.
              They actually worry about that? It feels like Fedora has always been late.

              Comment


              • #27
                Originally posted by brent View Post
                Fedora 34: ship both PulseAudio and PipeWire, set PulseAudio as default
                That is what Fedora is doing since several versions. 🙄

                Comment


                • #28
                  Originally posted by finalzone View Post

                  Add the following

                  Code:
                  sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing
                  to get the latest stable release of pipewire-pulseaudio which fixes the issue. You may need to manually enable pipewire-pulseaudio service via systemctl.
                  Code:
                  systemctl --user enable pipewire pipewire-pulseaudio
                  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.

                  Comment


                  • #29
                    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 ?

                    Comment


                    • #30
                      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.
                      Couldn't this package do the trick ?
                      https://www.archlinux.org/packages/e...pipewire-alsa/

                      Comment

                      Working...
                      X