Announcement

Collapse
No announcement yet.

Wine Developers Fight Over PulseAudio Driver

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

  • #16
    Originally posted by drag View Post
    Saying pulseaudio is a third party product is like saying that your X Server is a third party product.
    X doesn't try to replace an existing API.

    """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."""
    X doesn't try to replace an existing API.

    A audio server performs a similar function to the display server. It provides a intelligent way to manage audio I/O and multiple applications.
    ALSA somewhat tried, but it wasn't enough. Instead of fixing ALSA, we have PA.

    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.
    Exactly. It shouldn't have been that way. What PA does now, ALSA should be able to do.

    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.
    Then there's people who don't understand the discussion.

    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.
    Maybe you're not intelligent enough yourself to understand the discussions.

    Comment


    • #17
      Originally posted by ShadowBane View Post
      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.
      PA is not ASIO or ReWire. PA is trying to be the new ALSA. Which is wrong.

      Comment


      • #18
        Originally posted by ShadowBane View Post
        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.
        Applications don't have to deal with it. Whatever it does, it does it transparently.

        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 backwards compatibility stuff. ALSA for example also supports OSS. Nothing wrong with that. If Windows wouldn't support DS/DM, Windows XP games wouldn't run anymore, and if ALSA wouldn't support OSS, old Linux games/apps wouldn't run anymore either.

        This is beofore adding all of the third-party stuff like ASIO, gstreamer, phonon, SDL, etc.
        They serve a completely different purpose than what PulseAudio does.

        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.
        All stuff that ALSA should be handling to begin with.

        Comment


        • #19
          Originally posted by RealNC View Post
          X doesn't try to replace an existing API.
          Qt, GTK, EFL, wxwindows and company do. Why do we need graphics toolkits getting between us and the low level apis? Xorg drawing methods should be good enough for anyone, right? We only need a low level implementation?

          Originally posted by RealNC View Post
          Maybe you're not intelligent enough yourself to understand the discussions.
          And here we get to the real argument. Give this guy some applause, he can resort to ad hominem attacks to make sure everyone knows how correct his point is.

          Comment


          • #20
            Originally posted by ShadowBane View Post
            Qt, GTK, EFL, wxwindows and company do. Why do we need graphics toolkits getting between us and the low level apis? Xorg drawing methods should be good enough for anyone, right? We only need a low level implementation?
            Qt, GTK and EFL don't try to replace an existing API. X11 does not provide widgets.

            And here we get to the real argument. Give this guy some applause, he can resort to ad hominem attacks to make sure everyone knows how correct his point is.
            It's you who does that, having no clue about technical details. You don't even know what Qt and GTK are, and that ALSA is not only a kernel API but provides an extensive user-space application library that PulseAudio is trying to replace instead of enhance.

            Comment


            • #21
              Can someone correct my understanding?

              Also provides the driver to the hardware. The result is that you get a device to which only a single application can connect. Example "Card 0"
              Also provides the ability to define multiple 'virtual' devices via the .asoundrc which attach to the card via dmix (Example vcard0, vcard1, vcard2)
              Each application needs to communicate with it's own individual VCard.
              Pulse creates a single interface (PVcard0) to which all applications can connect. It does it's own mixing, sample rate conversion, and sends it to Alsa's "Card 0"

              Is this correct?

              F

              Comment


              • #22
                Originally posted by russofris View Post
                Can someone correct my understanding?

                Also provides the driver to the hardware. The result is that you get a device to which only a single application can connect. Example "Card 0"
                Also provides the ability to define multiple 'virtual' devices via the .asoundrc which attach to the card via dmix (Example vcard0, vcard1, vcard2)
                Each application needs to communicate with it's own individual VCard.
                Nope. All applications open a single device. Output to that device is then mixed together by dmix.

                Comment


                • #23
                  Originally posted by asdx
                  So Wayland should not exist because there is X and Wayland is trying to replace X' API?
                  X isn't getting fixed because of all the legacy stuff in it. ALSA doesn't have that problem.

                  Your analysis is shit. PA has fixed most of ALSA and works really well for most people so shut the fuck up.
                  PA doesn't fix ALSA, it replaces it, so blow me and go fuck yourself, you piece of shit.

                  PS:
                  Apologies to the other readers for having to read this. I always respond in kind.
                  Last edited by RealNC; 06-27-2012, 04:23 PM.

                  Comment


                  • #24
                    Originally posted by RealNC View Post
                    It matters because now it's not guaranteed that PA is installed. So developers need to implement ALSA as well as PA support.
                    No they don't. PulseAudio is installed by default on every distribution that matters and you can simply depend libpulse and then even setups that do not have PulseAudio should work.


                    Originally posted by RealNC View Post
                    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.
                    Dmix is a dirty hack that doesn't work well in multichannel setups for example. PulseAudio does the mixing like it should be done and it also supports numerous features that are not available for any other audio server for Linux. There's a reason why it's used by default in just about every single Linux distribution and mobile operating system (maemo, webOS, Mer, MeeGO, Tizen...) out there. It's simply the superior solution.

                    Originally posted by RealNC View Post
                    All stuff that ALSA should be handling to begin with.
                    Having all these features in kernel would make no sense what-so-ever and if they are implemented in user space they can as well be in PulseAudio.

                    Originally posted by RealNC View Post
                    Applications don't have to deal with it. Whatever it does, it does it transparently.
                    So does PulseAudio... seriously what are you talking about?

                    Originally posted by RealNC View Post
                    PA is not ASIO or ReWire. PA is trying to be the new ALSA. Which is wrong.
                    The developement of PulseAudio started in year 2004 and it has been used exlusively for the past five years. ALSA has established itself as userspace interface for kernel drivers for other audio servers like PulseAudio and Jack to use. You subjective opinion of something being wrong doesn't really hold much value in this case and seriously what is your point here? Should we just throw away all the developement that has happenend in Linux audio stack for the past years and go back fixing some unfixable mess that isn't even used anymore?

                    Comment


                    • #25
                      Originally posted by Teho View Post
                      No they don't. PulseAudio is installed by default on every distribution that matters and you can simply depend libpulse and then even setups that do not have PulseAudio should work.
                      Yes, though many users remove it. And since now you can create a setup where ALSA applications can be redirected seamlessly to PulseAudio, it makes more sense to support ALSA only. The PA API makes less sense now.

                      Dmix is a dirty hack that doesn't work well in multichannel setups for example. PulseAudio does the mixing like it should be done
                      But dmix should have done that to begin with.

                      and it also supports numerous features that are not available for any other audio server for Linux. There's a reason why it's used by default in just about every single Linux distribution and mobile operating system (maemo, webOS, Mer, MeeGO, Tizen...) out there. It's simply the superior solution.
                      It does solve a whole lot of problems. But it does that using the wrong approach. The userspace part of ALSA should be doing that. Everything should be nicely integrated using a single API instead of two.

                      Having all these features in kernel would make no sense what-so-ever and if they are implemented in user space they can as well be in PulseAudio.
                      I do agree. But you're forgetting that ALSA-lib was created to handle all the userspace stuff. ALSA has two parts, one in kernel space, one in user space. PA is trying to replace the user space part of ALSA. It would make more sense to enhance user space ALSA instead of replacing it.

                      So does PulseAudio... seriously what are you talking about?
                      I am talking about an unneeded API.

                      The developement of PulseAudio started in year 2004 and it has been used exlusively for the past five years. ALSA has established itself as userspace interface for kernel drivers for other audio servers like PulseAudio and Jack to use. You subjective opinion of something being wrong doesn't really hold much value in this case and seriously what is your point here? Should we just throw away all the developement that has happenend in Linux audio stack for the past years and go back fixing some unfixable mess that isn't even used anymore?
                      There's two approaches to fixing something. a) try to fix the existing code and b) rewrite the existing code. PA did neither. It just threw another API in there. So when something turns up in PulseAudio that doesn't work well in the future, let's create yet another one. We'll call it NewAwesomeAudio which replaces PulseAudio. And later, when problems with that turn up, we'll go for yet another new API.

                      No. If there's a problem, fix it.

                      Comment


                      • #26
                        Lol, Safari auto corrected "Alsa" to "Also".

                        Comment


                        • #27
                          Originally posted by asdx
                          YOU are the piece of shit. Nobody would blow you anything, since you probably have a 1-inch penis.

                          Go fuck yourself and kill yourself or die in a fire you pathetic, piece of shit loser.
                          Can't we all just hug and get along?

                          Comment


                          • #28
                            Originally posted by asdx
                            YOU are the piece of shit. Nobody would blow you anything, since you probably have a 1-inch penis.

                            Go fuck yourself and kill yourself or die in a fire you pathetic, piece of shit loser.
                            hey guys come down and don't talk like winDOS people. !rolleyes!

                            Comment


                            • #29
                              Originally posted by RealNC View Post
                              Nope. All applications open a single device. Output to that device is then mixed together by dmix.
                              Are you certain? Then why does PA exist? I was under the impression that this was the major obstacle that PA was created to overcome. I distinctly recall having to mess around with my .asoundrc and creating multiple virtual cards in order to get two applications to playback simultaneously under Alsa, and to assign a volume to each individual application. This was some time ago though (2006-ish).

                              F

                              Comment


                              • #30
                                Originally posted by RealNC View Post
                                Yes, though many users remove it. And since now you can create a setup where ALSA applications can be redirected seamlessly to PulseAudio, it makes more sense to support ALSA only. The PA API makes less sense now.
                                I don't think so. PulseAudio is still the de facto audio server so supporting it as well as possible should be the top priority.

                                Originally posted by RealNC View Post
                                There's two approaches to fixing something. a) try to fix the existing code and b) rewrite the existing code. PA did neither. It just threw another API in there. So when something turns up in PulseAudio that doesn't work well in the future, let's create yet another one. We'll call it NewAwesomeAudio which replaces PulseAudio. And later, when problems with that turn up, we'll go for yet another new API.
                                PulseAudio takes radically different approach to the problem than ALSA so just rewriting stuff isn't possible. I still don't understand why you think that ALSA API is the end of all Linux audio APIs. I mean seriously even if ALSA was extended so far that it would resemble the PulseAudio we have now its APIs would have probably changed completely anyway.

                                Originally posted by RealNC View Post
                                No. If there's a problem, fix it.
                                PulseAudio did just that.

                                Comment

                                Working...
                                X