Announcement

Collapse
No announcement yet.

PipeWire Is In Increasingly Great Shape - Ready For More User Testing

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

  • #21
    Originally posted by pkunk View Post


    Something like:
    • systemctl --global mask pulseaudio.service
    • pacman -S pipewire-pulse
    • create /etc/ld.so.conf.d/pw-pulse.conf with /usr/lib/pipewire-0.3/pulse
    • add NoExtract = usr/lib/libpulse* to pacman.conf
    • pacman -S libpulse
    • reboot

    Don't use wireplumber it currently doesn't work with the latest pipepewire.
    Multilib and flatpaks will not support this setup.
    It would be surprising if Bluetooth works.
    Thank you very much for the detailed information. However as I was researching things along the way it appeared from many current comments that PipeWire couldn't yet completely replace PA, which is why I never attempted to completely disable it. Am I wrong though? Because if I am I'll give your method a try!

    Comment


    • #22
      Originally posted by kpedersen View Post
      ...I personally am a little surprised they aren't committing a little more resources to remote server UI tech...
      They do commit resources to remote server UI tech, its called cockpit: https://cockpit-project.org/

      Comment


      • #23
        Originally posted by muncrief View Post

        Thank you very much for the detailed information. However as I was researching things along the way it appeared from many current comments that PipeWire couldn't yet completely replace PA, which is why I never attempted to completely disable it. Am I wrong though? Because if I am I'll give your method a try!
        It seems ready for early adopters but not for general use.
        It plays sound sees soundcard, allows to control volume. But volume control seems strange compared with pulseaudio. I play around with it a little it seems ok for simple scenarios. But it doesn't work with Steam in flatpak and it is no go for me.

        Comment


        • #24
          Originally posted by Slartifartblast View Post
          Hmm, I remember the early days of pulseaudio, I just hope it isn't pulseaudio 2 bugfest.
          Considering the original name of PipeWire is PulseVideo, your hope may be in vain. Still worth it if it can be fixed up the same way PA was.

          Comment


          • #25
            Originally posted by browseria View Post

            They do commit resources to remote server UI tech, its called cockpit: https://cockpit-project.org/
            From that little web UI, I only see a button to "Terminal". If that is all they can provide (rather than VNC, RDP or something better) then that is a pretty weak offering.

            Comment


            • #26
              Should Linux finally merge the RT patchset, this pipewire thing might even be useful.

              Using jackd is a joke without PREEMPT_RT.

              Comment


              • #27
                Originally posted by Slartifartblast View Post
                Hmm, I remember the early days of pulseaudio, I just hope it isn't pulseaudio 2 bugfest.
                The only real way to find out is for us to test it and report bugs, then it all comes down to whether or not the pipewire devs respond appropriately.

                Comment


                • #28
                  Originally posted by muncrief View Post
                  I have great hope for PipeWire but after spending a few days dedicated to trying to get it to work on Arch recently I had to surrender to defeat. It's very much in the baby steps phase right now, and wants Wayland Gnome very, very, badly. And good god, I can't run things like Gnome and KDE, they just drive me up the wall with all their spinny bleepy things and the ludicrous complexity demanded to do the simplest of things. For example, I was never even able to create a simple, unified, customized, cascading menu on either one.
                  Happy to see that you're at least trying. I don't have much motivation to mess around with it even though it's something that I'll need as my daily driver. In terms of Wayland and Flatpak.


                  However I have a great bias towards the simple, direct, and efficient. And realize many people absolutely love Gnome and KDE, and consider things like XFCE stone age technology
                  I used Openbox for a long time it's awesome! I still find myself in KDE most of the time. I do miss the days of using efficient software (not using javascript) and spending time to configure "the perfect environment". These days I optimize for productivity which means using very inefficient software. I regularly swap between environments (including macOS and Windows). I don't like it, but it's a means to an end. I would really love to use Sway for my daily driver, but I have pain with some proprietary software that I _need_ to run :-3

                  Which of course is one of the wonderful things about Linux. If you have the interest and patience to learn you can literally make it anything you want.
                  Well said. The student I used to be would agree with you. The "adult" that I have become things of it this way: Imagine living in a town where each person decides on which side of the road they want to drive. It's not very inefficient, at least not in terms of my culture.

                  The distinction that I'm trying to make is that it's okay to mess around with stuff for fun or to learn. In terms of shell/DE it makes sense to tailor it to one's specific workflows or even just to express creativity. On the other side when you're trying to unify core components of an operating system that many projects will depend on then internal-dependency-management, planning, and cooperation becomes vital. You want as much feedback from the community at the early stages of the project IMO as possible. That's just my take on it. I'm not speaking about pirewire specifically, just the annoyance over the decades about not abstracting non-GUI-logic an application instead of abstracting and avoiding duplicate work and maintenance burdens.

                  A project like pipewire is much needed and so many different aspects. Everyone want it to be successful for their use case.

                  Anyway. Good luck Wim! Hope you'll make us proud.

                  Comment


                  • #29
                    Hmm... I wonder if replacing my audio server to pipewire will mitigate a pulse bug I have where starting an input stream while the device is already outputting audio will cause pulse to suddently change frequency. That makes everything sound either lower or higher than normal. I have to kill and powercycle the device. I'm using a scarlett 2i2.

                    Comment


                    • #30
                      PulseAudio still sucks balls, even today. JACK worked okay, but like others said, it's not too useful without a pre-emptive kernel. Barring that, I just want a pure ALSA system, as that seems to work great.

                      PulseAudio was one of the reasons why I stopped using Red Hat / Fedora and never went back.

                      Comment

                      Working...
                      X