Announcement

Collapse
No announcement yet.

PipeWire 0.3.22 Released With Many Improvements

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

  • #31
    Originally posted by pal666 View Post
    you hinted and laughed at something else. like "they didn't test every possible setup". well, that's obviously impossible to do
    No, i was really quite specific. Then you wrote some random crap in quotes that i never said to justify yourself? please.

    Comment


    • #32
      Originally posted by angrypie View Post
      You can tell Pipewire is a serious project when they implement in a few months stuff that took years for Poettering to fix.
      And yet they are still unable to remix stereo to all channels with pulse daemon. Because who needs bass with music, right?

      Comment


      • #33
        Originally posted by Danny3 View Post

        While not as good as a real system, but I think they can test with 5.1 or 7.1 headphones.
        I have a pair of 5.1 headphones. They say it's 7.1 and even allows me to set 7.1 from Realtek control panel on Windows, but I think they're lying as I have only two 3.5 mm jacks.
        Still, when you cannot afford or carry a real surround system, these are pretty good.
        Not sure it's very representative. Maybe for a 5.1 soundbar directly hooked to your graphics card or motherboard. But a sound bar still only fake surround sound.
        But for actual 5.1/7.1/Atmos, you'll need an AV receiver processing and distributing the sound where it's due. And that has always been tricky on Linux. I have no clue how it's faring on other OSes.

        When Pulseaudio came out, it worked mostly well, but needed some tweak to daemon.conf and default.pa for proper 5.1 or to order the channels (left and right were inverted or no 5.1, etc...). It was only solved around 2015 for me. Although I'm not sure LFE-remixing has ever been solved (bass redirecting).
        Then amdgpu grew between 2017-2018 and I had a whole new lot of sound and video passthrough issues for 18 months. It finally matured enough for these to be solved.

        My point is I don't think it'll be enough with headphones. Hooking to an AV receiver (for the real surround experience) has always been tricky and you can't just simulate that.

        Comment


        • #34
          Originally posted by angrypie View Post
          You can tell Pipewire is a serious project when they implement in a few months stuff that took years for Poettering to fix.
          Can you please inform your self, at least a tiny bit, before posting garbage. The pipewire and pulseaudio projects worked together to split out all the policy and audio setup code in pulseaudio to a library. So, the reason Pipewire have been able to get things working so well so fast, is because they are actually using puleaudio for the configuration and setup.

          Comment


          • #35
            Pipewire switch over seemed fine until I wanted to play some media files with surround sound encoding, all I get out of vlc is static. Switching back to pulse and they play fine - other than that I barely noticed any difference in my testing

            Comment


            • #36
              Originally posted by AnAccount View Post

              Can you please inform your self, at least a tiny bit, before posting garbage. The pipewire and pulseaudio projects worked together to split out all the policy and audio setup code in pulseaudio to a library. So, the reason Pipewire have been able to get things working so well so fast, is because they are actually using puleaudio for the configuration and setup.
              Source: trust me bro

              Comment


              • #37
                Originally posted by Mez' View Post

                Not sure it's very representative. Maybe for a 5.1 soundbar directly hooked to your graphics card or motherboard. But a sound bar still only fake surround sound.
                But for actual 5.1/7.1/Atmos, you'll need an AV receiver processing and distributing the sound where it's due. And that has always been tricky on Linux. I have no clue how it's faring on other OSes.

                When Pulseaudio came out, it worked mostly well, but needed some tweak to daemon.conf and default.pa for proper 5.1 or to order the channels (left and right were inverted or no 5.1, etc...). It was only solved around 2015 for me. Although I'm not sure LFE-remixing has ever been solved (bass redirecting).
                Then amdgpu grew between 2017-2018 and I had a whole new lot of sound and video passthrough issues for 18 months. It finally matured enough for these to be solved.

                My point is I don't think it'll be enough with headphones. Hooking to an AV receiver (for the real surround experience) has always been tricky and you can't just simulate that.
                I don't get why this is so bad for you. You hook the multi-channel receiver into the hdmi out of the gpu and it should work great on any OS as long as you have a driver worth using. The software (game, entertainment player, etc) is the worst offender today. Many game devs don't include support for greater than stereo.

                The best alternative to get multi-channel sound when software limits it is to have a receiver that upgrades it with processing. Fake yes, but still sounds great when a receiver does it well.

                It was worse before gpu's and motherboards came with hdmi out. Not so bad since. I don't consider it tricky at all. Plug hdmi into gpu. Get good gpu driver. Profit. That's it. If it takes more than that for you, I don't get it. Your system is broken.
                Last edited by ix900; 22 February 2021, 03:13 PM.

                Comment


                • #38
                  Originally posted by angrypie View Post
                  You can tell Pipewire is a serious project when they implement in a few months stuff that took years for Poettering to fix.
                  Poettering is not working on pulseaudio for more than 10 years...

                  Comment


                  • #39
                    Originally posted by angrypie View Post

                    Source: trust me bro
                    From

                    https://github.com/PipeWire/pipewire

                    "PulseAudio applications still use the regular PulseAudio client libraries"

                    Any improvements done by PulseAudio developers at the ALSA kernel layer continue to be leveraged by everyone including PipeWire. Look at the architecture for details on that.

                    Comment


                    • #40
                      Originally posted by RahulSundaram View Post

                      From

                      https://github.com/PipeWire/pipewire

                      "PulseAudio applications still use the regular PulseAudio client libraries"

                      Any improvements done by PulseAudio developers at the ALSA kernel layer continue to be leveraged by everyone including PipeWire. Look at the architecture for details on that.
                      I see you had miss read.
                      The pipewire and pulseaudio projects worked together to split out all the policy and audio setup code in pulseaudio to a library. So, the reason Pipewire have been able to get things working so well so fast, is because they are actually using puleaudio for the configuration and setup.

                      This is not in fact true. Pipewire has a pulseaudio replacement server. This does not use the same policy or setup as pulseaudio yes able to talk pulseaudio protocol so perfectly that client side libraries work mostly.

                      https://gitlab.freedesktop.org/pipew.../Configuration Fixes you have done in the pulseaudio configuration files on disc if required need to be redone in the pipewire configuration files.

                      Pipewire has a proper per application policy system suitable for use with flatpak and others that pipewire does not. So yes pipewire has a different policy engine just a policy engine that is mostly compatible with pulseaudio policy engine for running pulseaudio applications. Please note I said mostly compatible there are things you can do with pactl to attempt to change policy and the policy will not change with pipewire because its not supported these are fairly exotic settings but do absolute prove that the policy engines are in fact completely different. Remember pipewire policy engine is design to support most of the policy engine features of features jack audio and pulseaudio and other parts its most because there are cases where both are not doable and one has to chosen this is not all pulseaudio policy engine features are in pipewire. There are also feature pipewire has never implemented that appear to be totally not used by any normal application that were both added to jack audio and pulseaudio because some developer thought they were a good idea at the time.

                      daemon/server side of pulseaudio and pipewire there are lots of differences. The way the buffers internally are done in pipewire is way different to pulseaudio resulting in the daemon/server configuration being very different. Yes this is the bug pulseaudio picked up from the first developer starting on a defective audio driver and thinking that is how audio should work. True Low latency with pipewire is either direct pipewire or jackaudio interfaces not the pulseaudio interfaces.

                      Yes pipewire picks up a lot from the work Pulseaudio developers have like like the Alsa driver improvements but the policy engine and configuration is not one of these things.

                      Comment

                      Working...
                      X