Announcement

Collapse
No announcement yet.

Wine Developers Fight Over PulseAudio Driver

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

  • Wine Developers Fight Over PulseAudio Driver

    Phoronix: Wine Developers Fight Over PulseAudio Driver

    It's not yet time for another Wine development release, but there's a heated discussion to point out on the development list concerning a PulseAudio driver for Wine...

    http://www.phoronix.com/vr.php?view=MTEyODM

  • #2
    pulseaudio : a fix for a problem that didn't exist. (not completely true, but a wrong fix anyhow : fixing something by adding a layer of complexity is plain wrong)
    I hate pulseAudio, for me it caused nothing but trouble (HTPC, desktop and laptop). Using pure ALSA hasn't yet let me down. The craziness it allows me to do is everything anyone can ask for (I even used it to stream audio of a movei to a different PC). Yes it takes a day of digging through docs/tutorials, but it IS possible.
    Also when using pulse on a relatively good sound system, I got the feeling that it somehow distorted the sound; I'll have to do an analysis at some point...
    And don't get me started on digital passthrough.

    rant off...

    Serafean

    Comment


    • #3
      I love PulseAudio, combined with VeroMix it's extremely easy to manage everything related to sound, and the sound recording quality has jumped up immensely since I started using it. So a PulseAudio driver in Wine is very important for me - it would solve multiple sound quality issues. For instance, if I set PulseAudio to use the traditional interrupt-based scheduling method, then everything works correctly, except for Wine, which plays corrupted sound and everything runs in twice the speed (crazy!). And if it's set to the new timer-based method, Wine works fine, yet VLC has corrupted sound. Earlier there also was an issue with sound quality that way, but it's fixed since PA 2.0. Any problems people may be having these days with PA is just because of misconfiguration. "man pulse-daemon.conf" is your friend!

      So I don't care which PA driver goes into Wine, as long as it gets there already!

      Comment


      • #4
        Please, please, please, put in Pulse Audio in Wine...!!! It's the advance way to go.

        Yeah I'm aware there is a PA Wine version PPA on launchpad.

        Comment


        • #5
          Originally posted by Serafean View Post
          pulseaudio : a fix for a problem that didn't exist. (not completely true, but a wrong fix anyhow : fixing something by adding a layer of complexity is plain wrong)
          I hate pulseAudio, for me it caused nothing but trouble (HTPC, desktop and laptop). Using pure ALSA hasn't yet let me down. The craziness it allows me to do is everything anyone can ask for (I even used it to stream audio of a movei to a different PC). Yes it takes a day of digging through docs/tutorials, but it IS possible.
          Also when using pulse on a relatively good sound system, I got the feeling that it somehow distorted the sound; I'll have to do an analysis at some point...
          And don't get me started on digital passthrough.

          rant off...

          Serafean
          Pulseaudio does not adds another layer of complexity. All it does is replace alsa userspace, that is in fact, very badly maintained and buggy. Pulseaudio, alsa userspace and Jack leverages the actual driver implementation to the alsa kernel modules.

          The problem comes when you want to use more than one together...

          Comment


          • #6
            PA exists due to ALSA's shortcomings. If the ALSA devs had gotten it right, there would never have been a need for PA. Unfortunately, ALSA didn't get it right, and now we have to deal with two low-level layers of audio instead of just one. What a mess. ALSA should have learned from OS X and Windows about how to do it right.

            Comment


            • #7
              Originally posted by RealNC View Post
              PA exists due to ALSA's shortcomings. If the ALSA devs had gotten it right, there would never have been a need for PA. Unfortunately, ALSA didn't get it right, and now we have to deal with two low-level layers of audio instead of just one. What a mess. ALSA should have learned from OS X and Windows about how to do it right.
              It makes sense to have a layer to hardware. It allows other top layers like PA to compete. The structure also allows for ALSA to be replaced and keep top layers still relative.

              Comment


              • #8
                Originally posted by e8hffff View Post
                It makes sense to have a layer to hardware. It allows other top layers like PA to compete.
                There should be no competition. There should only be one API. Top layers should be things like SDL, OpenAL, PortAudio, stuff like that. Third-party low-level APIs like PA should not exist. The existence of PA is proof of Linux's failure in audio.

                Comment


                • #9
                  Originally posted by RealNC View Post
                  There should be no competition. There should only be one API. Top layers should be things like SDL, OpenAL, PortAudio, stuff like that. Third-party low-level APIs like PA should not exist. The existence of PA is proof of Linux's failure in audio.
                  Why and how? I mean what does it matter who provides the userspace part of the Linux audio stack. ALSA is for the drivers and PulseAudio does the mixing, filtering, routing and so on. From developers perspective ALSA doesn't matter as they either target GStreamer, OpenAL, Phonon... or PulseAudio directly because it's the de facto audio server on Linux.

                  Comment


                  • #10
                    If the ALSA devs got it so wrong, why on earth didn't the PA devs work on fixing the issues with ALSA instead of adding a whole new layer of broken on top? Actually I'm glad they didn't go that (otherwise correct) route because they probably would have just fucked up ALSA like they did PA, and it would be a bit more difficult methinks to just uninstall ALSA to make everything work properly again like you can with PulseAudio.

                    If "apt-get autoremve pulseaudio" solves your audio problem, reading the manpage was never a proper solution. If Pulse Audio is so misconfigured out of the box that it can't function as well as ALSA does without PulseAudio, that to me sounds like the definition of a broken piece of crap solving a problem that doesn't exist.

                    Comment


                    • #11
                      Every layer added to your audio pipeline will add latency, to say nothing of excessive layering introducing unnecessary compatibility issues and bugs.

                      I would really like to see OSSv4 adopted as the de-facto standard. It has a simple API, includes software mixing and virtually everything anyone could want. I don't think Linux needs its own audio API just to be different from everyone else.

                      Comment


                      • #12
                        Originally posted by Teho View Post
                        Why and how? I mean what does it matter who provides the userspace part of the Linux audio stack.
                        It matters because now it's not guaranteed that PA is installed. So developers need to implement ALSA as well as PA support.

                        ALSA is for the drivers and PulseAudio does the mixing, filtering, routing and so on.
                        No, ALSA also does the mixing (dmix) and provides lots of plugins in libalsa. PA tries to fix the problems in those parts of ALSA, problems that should not exist to begin with. PA exists because of problems in ALSA.

                        Again, the focus is "problems in ALSA." There shouldn't be any.

                        From developers perspective ALSA doesn't matter as they either target GStreamer, OpenAL, Phonon... or PulseAudio directly because it's the de facto audio server on Linux.
                        That doesn't make it right.

                        Comment


                        • #13
                          There should be no competition. There should only be one API. Top layers should be things like SDL, OpenAL, PortAudio, stuff like that. Third-party low-level APIs like PA should not exist. The existence of PA is proof of Linux's failure in audio.
                          Saying pulseaudio is a third party product is like saying that your X Server is a third party product.

                          """There should only be one API. Top layers should be things like GTK, OpenGL, Motif, stuff like that. Third-party low-level APIs like Xserver should not exist. The existence of Xserver is proof of Linux's failure in graphics."""

                          A audio server performs a similar function to the display server. It provides a intelligent way to manage audio I/O and multiple applications.

                          I suffered through using Alsa for years. I did many advanced things like setup custom configurations to multiplex audio inputs and all sorts of junk like that. And I can tell you from experience that Linux audio is shit without Pulseaudio.

                          There is little proof needed beyond then the continued misunderstanding and misrepresentation of Pulseaudio show that there is still a large segment of the Linux user community that are not interested the least in understanding the technology of the software they are using and just run off of little more then emotionally fueled ignorance.

                          Every once and a while I run into something intelligent somebody says that shows that PA sucks in some way, but that's rare nowadays.

                          Comment


                          • #14
                            Originally posted by RealNC View Post
                            PA exists due to ALSA's shortcomings. If the ALSA devs had gotten it right, there would never have been a need for PA. Unfortunately, ALSA didn't get it right, and now we have to deal with two low-level layers of audio instead of just one. What a mess. ALSA should have learned from OS X and Windows about how to do it right.
                            Windows (starting with vista) also runs a sound server that does similar stuff to what PA does but has less features. I can't speak to how the OS X audio system works as I have basically never used it let alone looked into how it worked.

                            Also, for those who are complainging about having one more API to target: Microsoft provides WASAPI DirectSound/DirectMusic, Media Foundation and Windows multimedia waveXxx and mixerXxx functions by default. This is beofore adding all of the third-party stuff like ASIO, gstreamer, phonon, SDL, etc.

                            I have found PA to be a huge benefit, running multiple sound devices or trying to do per-application volume control without it is painful to say the least.

                            Comment


                            • #15
                              Originally posted by TechMage89 View Post
                              Every layer added to your audio pipeline will add latency, to say nothing of excessive layering introducing unnecessary compatibility issues and bugs.
                              If this is the case, tell me why pro audio stuff on linux tends to not support alsa directly. Also, if extra layers were bad things like ASIO and ReWire wouldn't exist on windows/mac.

                              Comment

                              Working...
                              X