Announcement

Collapse
No announcement yet.

PipeWire 0.3.46 Released With Critical Bug Fixes, Better Sound Sharing With Zoom

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

  • #11
    Originally posted by chuckula View Post
    I need to check but I think I got hit by that devices not being listed bug. 0.3.44 worked fine on a custom kernel (a 5.16 one so it's not old) but 0.3.45 suddenly died with errors about not detecting the sound devices even though all the drivers were loaded and ALSA could see the card.
    Same issue was on Mandriva in 0.3.45. PipeWIre change somethings in line Pipe <=> kernel and to work fine in 0.3.45 it requires kernel recompiled with this changes: https://github.com/OpenMandrivaAssoc...9febd20299d53e

    or if you can't recompile, just patch pipewire https://github.com/OpenMandrivaAssoc...879ba08cb3a167

    But looks like 0.3.46 aleady fix it.

    Comment


    • #12
      Seems like PW supports virtual 7.1 sound directly. Thinking about it, it's probably possible with raw ALSA .asoundrc shenanigans using LADSPA plugins. I'm happy with PA as it is as shocking as that might sound, even for low latency (<5ms easily with Intel HDA + ALC295 codec, the kernel driver shits the bed before PA does if I go lower), but it tends to use way more CPU than should be necessary. Should't take anywhere near 20% of a core, even with virtual 7.1, convolver eq and compressor together. On Windows that's more like 5% total. It's hardly noticeable at all.

      EDIT: Doesn't work for me... Like half a year ago or so it just gives me some BS about dbus system bus not found and some other crap when I run "pipewire" (I actually have dbus installed, for better or worse) and then when I start something like mpv or pavucontrol it says connection refused/denied. The socket in $XDP_RUNTIME_DIR/pulse/native definitely exists, though. Not sure what's up with that. Seems like it might require some more configuration for dbus or whatever? But it didn't work even when I tried that dbus-launch snippet... Meh, I'll stick to PA, it just works, no dbus bullshit I don't care about. The PA API doesn't even touch dbus, so why is it required here? Unless I got something wrong this is nuts. That is to say, I'm not really impressed, at least not positively.
      Last edited by binarybanana; 17 February 2022, 04:15 PM.

      Comment


      • #13
        The Zoom desktop client for Linux is quite buggy for me in general. I was sharing on a call I was hosting earlier this morning (Fedora 35), we ended early and I had one person stay on for our 1:1 meeting, and I could not stop sharing no matter how many times I clicked the button. It does weird things with window occlusion when sharing that it doesn't on Windows (e.g. the Zoom controls over a window you are sharing). If I switch the audio focus of my KVM to another machine Zoom flips the shit out on Linux with this never ending stream of error notifications about not being able to detect my microphone that are ~75% as wide as my display (that don't stop even with the audio source switched back, I end up having to kill the app). The Windows client doesn't care. Zoom on Linux just straight up crashed the first time I tested screen sharing with the radeon driver. Lucky for me I immediately assumed I should switch to amdgpu, but they should really handle that more gracefully and tell users what they need to change. I'm super glad they actually care enough to make a Linux version of the client at all, I just hope they give it some love.

        Comment


        • #14
          Originally posted by binarybanana View Post
          Seems like PW supports virtual 7.1 sound directly. Thinking about it, it's probably possible with raw ALSA .asoundrc shenanigans using LADSPA plugins. I'm happy with PA as it is as shocking as that might sound, even for low latency (<5ms easily with Intel HDA + ALC295 codec, the kernel driver shits the bed before PA does if I go lower), but it tends to use way more CPU than should be necessary. Should't take anywhere near 20% of a core, even with virtual 7.1, convolver eq and compressor together. On Windows that's more like 5% total. It's hardly noticeable at all.

          EDIT: Doesn't work for me... Like half a year ago or so it just gives me some BS about dbus system bus not found and some other crap when I run "pipewire" (I actually have dbus installed, for better or worse) and then when I start something like mpv or pavucontrol it says connection refused/denied. The socket in $XDP_RUNTIME_DIR/pulse/native definitely exists, though. Not sure what's up with that. Seems like it might require some more configuration for dbus or whatever? But it didn't work even when I tried that dbus-launch snippet... Meh, I'll stick to PA, it just works, no dbus bullshit I don't care about. The PA API doesn't even touch dbus, so why is it required here? Unless I got something wrong this is nuts. That is to say, I'm not really impressed, at least not positively.
          Just try running two channel PA at 192kHz or higher in high priority or real-time mode and tell us about your experience
          .. and PW does a lot more than that

          Comment


          • #15
            How is the latency of pipewire compared to jack when using i/o usb audio devices today?

            Comment


            • #16
              Originally posted by binarybanana View Post
              Can PipeWire use PulseAudio modules, or does it at least have a multi-channel convolution engine that can be used for surround sound virtualization? PA got a huge update to their virtual-surround module and it's amazing. Sounds as good as HeSuVi on windows and does 7.1 without compromises. I use it with the OOYH (out of your head) HRIR and it's incredible how much it sounds like I've got a set of speakers all around me, even though I just got a pair of nice cans on my ears.
              Do you know if OOYH is available in any receivers or stand alone boxes so you don't have to route your HTPC through a computer? I pre ordered a Realizer A-16 only to be ripped off by the Smyth crooks. I still want the functionality though. OOYH isn't perfect in that it can't put the center in front of you only above you, for example. But it is still better than nothing for certain use cases.

              Comment


              • #17
                Originally posted by markus40 View Post
                Installed it on my laptop and MediaPC/Server doing both jobs very well;

                Laptop: speakers/headphones mostly browsing
                This is the most basic use case. Even plain ALSA can do this. Many ALSA drivers have a flag for switching between speakers/headphones on laptop chipsets. So this doesn't require any advanced functionality unlike the same use case with two sound cards.

                MediaPC/server: HDMI/soundbar with browsing, streaming, movies music and games.
                HDMI pass-through is basic functionality. Streaming / stream server/client functionality can be implemented with basic userspace utilies for airplay. Kodi/OpenElec has had this for years and all backends OSS/ALSA/PA work just fine. Games require lower latency, but I think even Pulseaudio is often sufficient.

                Comment


                • #18
                  Originally posted by kokoko3k View Post
                  How is the latency of pipewire compared to jack when using i/o usb audio devices today?
                  Comparable to JACK. See this for details https://gitlab.freedesktop.org/pipew...rmance#latency

                  Comment


                  • #19
                    Today I changed PA with PW, and after 4~5 hours of trying to fix the annoying stuttering issue (Intel Sunrise Point-LP HD Audio), I decided to back to PA.
                    Not going to try it again that fast.

                    Comment

                    Working...
                    X