Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • #76
    Originally posted by pingufunkybeat View Post
    On the downside, it doesn't seem to be ready, or significantly better than ALSA, and the people behind it already tried to hijack it and hold the Unix crowd ransom.
    If that happened, the solution would be a fork. OSSv4 is now licensed under the GPL so a fork would always be possible. We just need to keep 4Front on their toes about putting all of their work under the GPL (in addition to any other licenses) if they wish for OSSv4 to be adopted.

    Comment


    • #77
      you can control the volume in wesnoth independent from the volume in vlc. The app people just have to put it in. OSS is not needed for that.

      I wished pulseaudio would die a quick death. The average user does not gain anything by this trainwreck.

      Comment


      • #78
        Originally posted by darkphoenix22 View Post
        It comes down to this. ALSA can not be easily expanded. OSSv4 likely can.
        are you paid for this lying?

        Comment


        • #79
          Originally posted by energyman View Post
          you can control the volume in wesnoth independent from the volume in vlc. The app people just have to put it in. OSS is not needed for that.

          I wished pulseaudio would die a quick death. The average user does not gain anything by this trainwreck.
          Well, in the short term, PulseAudio does need to be abandoned as it has never achieved its original goals and likely never will.

          But its functionality needs to be replaced somehow. This would not be possible with ALSA unless we made another wrapper, which would have many of the same unavoidable problems as PulseAudio.

          The problem isn't that ALSA doesn't work. The problem is ALSA is too damn complicated to be usefully expanded while keeping ABI stability.

          Comment


          • #80
            Originally posted by energyman View Post
            are you paid for this lying?
            I just want a long term solution to the Linux audio problems and API/ABI complexity, which we aren't going to get by sticking with ALSA.

            Comment


            • #81
              Originally posted by darkphoenix22 View Post
              Abstraction is not a solution to ALSA's problems.
              What ARE Alsa's problems?

              It seems that the essential problems with ALSA cannot be reproduced by anyone, and are likely driver bugs.

              As you can see with PulseAudio, abstraction only exacerbates ALSA's flaws, namely it's complexity, while addding even more problems like high-latency.
              People use wrappers because it makes the code portable over several operating systems. What are you trying to do -- get OSSv4 accepted into Windows and MacOSX?

              OpenAL is needed, as is SDL, and they will not go anywhere. They deal with things that a low-level audio interface should not ever deal with.

              If that happened, the solution would be a fork. OSSv4 is now licensed under the GPL so a fork would always be possible. We just need to keep 4Front on their toes about putting all of their work under the GPL (in addition to any other licenses) if they wish for OSSv4 to be adopted.
              LOL, look how that worked the last time.

              It's a bit like advocating abandoning ext3/4 and switching to NTFS natively and then relying on keeping Microsoft on their toes.

              There is a VERY good reason why nobody is using OSS nowadays. They tried to hijack Linux, that's why.

              Comment


              • #82
                there are no abi/api problems. OSSv4 would make matters worse. Beside, what are the deep flaws of alsa? What functionality is needed? And if you start with the per-app volume again:
                that is not a problem. It has already been solved in Alsa. Just look up softvol, will you?
                Alsa is easily extendable. It can do everything you need. And unlike ossv4 its devs don't try to rip off anybody. OSSv4 must go away. So must pulseaudio. The first because its fanboys spread FUD the second because it is a very complicate solution in dire need of a problem.

                Comment


                • #83
                  Originally posted by pingufunkybeat View Post
                  What ARE Alsa's problems?

                  It seems that the essential problems with ALSA cannot be reproduced by anyone, and are likely driver bugs.
                  The problems with ALSA aren't functional, they're architectural. ALSA is simply too complex. It doesn't follow everything is a file and doesn't cleanly separate high-level from low-level.

                  Originally posted by pingufunkybeat View Post
                  People use wrappers because it makes the code portable over several operating systems. What are you trying to do -- get OSSv4 accepted into Windows and MacOSX?

                  OpenAL is needed, as is SDL, and they will not go anywhere. They deal with things that a low-level audio interface should not ever deal with.
                  I'm not asking for devs to program directly for OSSv4. I'm saying it's a "bad idea" to rely on abstraction to provide driver-level features, such as mixing and per-application volume controls. This stuff needs to be in the core audio API.

                  Originally posted by pingufunkybeat View Post
                  LOL, look how that worked the last time.

                  It's a bit like advocating abandoning ext3/4 and switching to NTFS natively and then relying on keeping Microsoft on their toes.

                  There is a VERY good reason why nobody is using OSS nowadays. They tried to hijack Linux, that's why.
                  A fork worked well enough for Xfree86 to create X.org Server. The same could be done for OSSv4 if the issue ever arises.

                  It's time we stopped letting politics decide the course of Linux development. Politics makes bad decisions and writes bad code.

                  Comment


                  • #84
                    Originally posted by energyman View Post
                    there are no abi/api problems. OSSv4 would make matters worse. Beside, what are the deep flaws of alsa? What functionality is needed? And if you start with the per-app volume again:
                    that is not a problem. It has already been solved in Alsa. Just look up softvol, will you?
                    Alsa is easily extendable. It can do everything you need. And unlike ossv4 its devs don't try to rip off anybody. OSSv4 must go away. So must pulseaudio. The first because its fanboys spread FUD the second because it is a very complicate solution in dire need of a problem.
                    Softvol is a hack. PulseAudio is a hack. Linux audio is being complicated by 232424 hacks.

                    There's a simple API that programs and libraries can use to provide sound. ALSA with 23352 hacks is not that API.

                    Jesus. I'm tired of all this political BS. Isn't open source supposed to be a meritocracy?

                    Comment


                    • #85
                      The problems with ALSA aren't functional, they're architectural. ALSA is simply too complex. It doesn't follow everything is a file and doesn't cleanly separate high-level from low-level.
                      What sort of mumbo-jumbo is that?!?!?

                      Software mixing has been a part of ALSA for ages. Why do you keep saying that it doesn't exist? It works just fine on every card I've tried.

                      Do you actually program for ALSA and OSSv4, and if you don't, where do you get all your information about "architectural problems" with ALSA?

                      I still don't see what I'd gain with PulseAudio and/or OSSv4, other than per-app volume, which might as well be added to ALSA instead.

                      Comment


                      • #86
                        Softvol is a hack. PulseAudio is a hack. Linux audio is being complicated by 232424 hacks.
                        How did you arrive at this number.

                        Could you name some of these hacks? No need for 232424, 10 will suffice.

                        Comment


                        • #87
                          Yes, ALSA has software mixing. But it doesn't have per-application volume controls. And look at all the effort it took to add software mixing to ALSA via dmix. It was enough for the devs to just make a wrapper with PulseAudio when they wanted per-app volume controls, instead of bothering to add it to ALSA itself.

                          This is not a long term solution.

                          Comment


                          • #88
                            Originally posted by pingufunkybeat View Post
                            I still don't see what I'd gain with PulseAudio and/or OSSv4, other than per-app volume, which might as well be added to ALSA instead.
                            The ALSA devs are never going to add per-app volume controls to ALSA or any other additional features. They'll just add it to PulseAudio, because even they don't want to bother with ALSA.

                            ALSA has very little active development besides maintenance. The majority of the devs have moved on to PulseAudio. ALSA is a dead end. Period.

                            Comment


                            • #89
                              wrong, it does have per-app volume control. Again, look up softvol. You are attacking alsa - but you don't know anything about it. Instead you get strung up on crap like 'does not handle everything as file' which is not a matter or 'does not seperate lowlevel' which is bullshit.

                              Comment


                              • #90
                                AlSA is easly extendable. Unlike OSSv4 which has how many devs left? 1? Or pulseaudio, which will fail like HAL failed.

                                Comment

                                Working...
                                X