Announcement

Collapse
No announcement yet.

PulseAudio 4.0 Brings Many Changes

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

  • #31
    Originally posted by Luke View Post
    It's one thing to point out that Pulseaudio add latency and lowers performance in an application where CPU capacity is tight, e.g 720p video on a netbook. The latter requires both no PA and no desktop compositing to work. It's quite another thing to simply talk hate about PA and people who worked their tails off to create it. That makes heat but little light and could even delay bugfixes by driving off developers.

    Before PA existed, I wondered why Windoze machines could mix sound but my Linux boxes could only have one device at a time claiming the sound card. Newer onboard sound on good desktop motherboards have hardware mixing, but my old $7 soundcards did not. Every added running service will use up CPU and add latency while also adding its own features. That means some folks will need to use it, others will need to not use it.

    I don't run PA on most of my machines, but it will work on all of them. The reason I don't is that 4 core processors playing AVCHD files use up all the available CPU performance, as does 720P H264 video on my netbook. My 8-core AMD can play even the "difficult" AVCHD files with PA running, but I keep my OS setups as clones of each other.

    On the other hand, I am not about to set up a machine with no hardware mixer for a "non-geek" end user without installing PA and making it work. Hell, without PA, my netbook requires JACK to be started just to play a mono sound file, as it's sound card lacks a mono channel. PA and JACK are literally the only way that machine can play a mono audio file. I use Jack for mixing on it, as I don't mind dealing with complexity to get 720p video playback on it, but that's not really something a distro could demand of all it's userbase. To distros: just don't make so many things depend on PA that users can't remove it for more performance or to deal with software that doesn't get along with PA.

    Yes, there are problems with PA. Use it if it works for you, remove it if it doesn't, and REPORT bugs, same as all other software. The goal should be to fix the problems, not drive off the devs so PA never gets improved again or disappears entirely.

    Disappear entirely.... That's the best option I think.

    Comment


    • #32
      Originally posted by duby229 View Post
      why would I want to test it on a distro that I don't use?
      To see if it is the software or the way it is set up or compiled in your distro. You know, troubleshooting, eliminating one possible cause after another until you find the real cause.

      Comment


      • #33
        Originally posted by duby229 View Post
        So in other words "PA improperly uses untested features of Alsa and so it must be Alsa's fault"

        That is also the most common erroneous defense used.

        EDIT: The fact is, whether you like it or not, Alsa works and PA does not.
        There is no "tested stable - safe to use" subsection of the alsa API. Using the API slightly differently than other applications is actually a /good/ thing in that it forces the entire API to be correct, not just a subsection of it.

        Comment


        • #34
          Originally posted by duby229 View Post
          So in other words "PA improperly uses untested features of Alsa and so it must be Alsa's fault"

          That is also the most common erroneous defense used.

          EDIT: The fact is, whether you like it or not, Alsa works and PA does not.
          You are assuming erroneous things. What I was pointing out is the ALSA has a bigger API surface that is used by PulseAudio and while ALSA developers themselves have tested it, as programs use it, you tend to find and fix issues and this is what happened here. The fact is that PulseAudio works for millions of users since majority of distributions are using it.

          Comment


          • #35
            Originally posted by BO$$ View Post
            I am not trolling anything. I tried a couple of days ago to get Rosegarden to work. It was a serious PITA. On windows I installed Ableton Live and worked without me configuring anything. On both I used MIDI to create sounds. Only on windows the results were good. Rosegarden, ignoring the shitty interface, didn't 'just work'.
            I really question why you use linux.
            You don't seem to like the software.
            You don't seem to like the ideology.

            Comment


            • #36
              Originally posted by duby229 View Post
              So in other words "PA improperly uses untested features of Alsa and so it must be Alsa's fault"

              That is also the most common erroneous defense used.

              EDIT: The fact is, whether you like it or not, Alsa works and PA does not.
              No... Its using untested codepaths. If the alsa developers say "Here's function calls A through Z, you can run them in any order you want, all dependency-calls are handled in specific functions. If C needs A and B, you dont have to call A, B, then C, C will call A then B, then C will actually execute. Don't worry about it." And then an application like Pulse actually puts that to the test, and it finds out that its NOT the case, that you DO have to call A, B, then C..... who's at fault? The Alsa developers for coding one thing and saying another, or the Pulse devs for believing them?

              When Pulse first came out in Ubuntu one of the big issues was that Pulse hit driver bugs because they were running portions of the audio drivers that no one had ever tried before. Those were BUGS in the -alsa- driver that had to be fixed. Who's to say that we fixed all the bugs? Maybe you guys ARE hitting bugs in the Alsa drivers and the reaction of "Well just dont run Pulse" is actually just a bandaid. If the bugs are in the alsa driver, you aren't actually fixing them. You're ignoring them.

              Now, maybe they ARE in Pulse, in which case they should be fixed too-- but they need to be reported first. And instead of actually CARING about the software people are using, you guys are taking the easy, lazy, way out and giving up without even trying.
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #37
                Originally posted by RahulSundaram View Post
                The experience in recent versions are much improved but unfortunately Debian (stable) is shipping is lagging behind quite a bit. Cherry picking newer versions from testing or unstable might be an option if you know what you are doing.
                I know what I'm doing and I'm a Sid/Experimental combo. Gnome 3.8.2 is just now moving into Sid/Unstable. PulseAudio will work for a few hours and then the mixer [gnome or kde kmix] instance of the 5.1 channels are gone [disappears in Gnome 3.8.2] and I'm back to relaunching kmix for the quick refresh into Alsa or I just go command line.

                Either way, Pulse crap the bed every time. I would think Desktop Environments would coordinate with PulseAudio [including the backends of VLC/Gstreamer] on a full QA testing schedule, publish the results and how their build flags should work [Debian is huge on this stuff] BEFORE a full release.

                In short, until it's out of a Google perpetual Beta don't release it as release quality.

                Comment


                • #38
                  Originally posted by Vim_User View Post
                  To see if it is the software or the way it is set up or compiled in your distro. You know, troubleshooting, eliminating one possible cause after another until you find the real cause.
                  I'm not changing my distro. It's not gonna happen. I have eliminated every possible cause, and every possible cause comes down to only PA.

                  Comment


                  • #39
                    Originally posted by RahulSundaram View Post
                    You are assuming erroneous things. What I was pointing out is the ALSA has a bigger API surface that is used by PulseAudio and while ALSA developers themselves have tested it, as programs use it, you tend to find and fix issues and this is what happened here. The fact is that PulseAudio works for millions of users since majority of distributions are using it.
                    I'm 100% certain that you are -HIGHLY- overrating how many people PA works for. You can claim that it works for millions of people, but the truth is far more likely to be that PA has detracted more users from linux than the number of people using it. And you can thank the dumbass major distro's for that.

                    I still havent found a single oob experience where PA works. Not one.

                    Comment


                    • #40
                      Originally posted by Marc Driftmeyer View Post
                      I would think Desktop Environments would coordinate with PulseAudio [including the backends of VLC/Gstreamer] on a full QA testing schedule, publish the results and how their build flags should work [Debian is huge on this stuff] BEFORE a full release.
                      Why would you think that? Desktop environment has zero history of doing any such thing and have not enough resources to do so for any component. There is basically like 3 people working on the entire audio stack in Linux doing any significant upstream development. One on PA and two on ALSA.

                      Comment

                      Working...
                      X