Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • I don't care where the code is. I only care if it doesn't allow apps and libraries to address ALSA like they expect. And if it reprocesses the audio and buffers the audio, causing extra latency.

    Comment


    • Sound APIs

      Recap for my own sanity:

      1) So with OSSv4, many functions that are not essential to run in kernel space are included there and it uses some bizarre method of interrupt handling that likely excludes it from kernel inclusion as well.

      2) PulseAudio causes issues with QoS in some circumstances due to how it handles driver interaction and buffering.

      3) We could use ALSA.

      I suppose the point of this argument from the beginning has been that the sound APIs preclude Linux from being a viable platform for Steam to release on because it would be too difficult for Valve and its clients (game manufacturers) to manage all of the differences.

      I think the real issue here is a surplus of choice and not many good ones.

      Is there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?

      Comment


      • Perfect summary. Thank you.

        Comment


        • Originally posted by darkphoenix22 View Post
          I don't where the code is. I only care if it doesn't allow apps and libraries to address ALSA like they expect. And if it reprocesses the audio and buffers the audio, causing extra latency.
          But if you're arguing for the complete elimination of a project due to a implementation specific failure then every project that's not perfect needs to be eliminated which doesn't leave us with much code.

          If an ALSA driver has a bug you don't throw all of ALSA out, you fix the driver. If Pulse has a specific issue with a particular piece of middleware then you can patch either the middleware, Pulse or both.

          Comment


          • Originally posted by p0larity View Post
            Recap for my own sanity:

            1) So with OSSv4, many functions that are not essential to run in kernel space are included there and it uses some bizarre method of interrupt handling that likely excludes it from kernel inclusion as well.

            2) PulseAudio causes issues with QoS in some circumstances due to how it handles driver interaction and buffering.

            3) We could use ALSA.

            I suppose the point of this argument from the beginning has been that the sound APIs preclude Linux from being a viable platform for Steam to release on because it would be too difficult for Valve and its clients (game manufacturers) to manage all of the differences.

            I think the real issue here is a surplus of choice and not many good ones.

            Is there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?
            Unfortunately there's no one perfect one size fits all solution so we can only choose from a pool of imperfect choices.

            Comment


            • Originally posted by mugginz View Post
              But if you're arguing for the complete elimination of a project due to a implementation specific failure then every project that's not perfect needs to be eliminated which doesn't leave us with much code.

              If an ALSA driver has a bug you don't throw all of ALSA out, you fix the driver. If Pulse has a specific issue with a particular piece of middleware then you can patch either the middleware, Pulse or both.
              It has issues with about 10 kinds of middleware.

              Again the problem with PulseAudio isn't the ideals. It's implementation. It breaks things as it meddles where it doesn't need to meddle.

              There no reason why PulseAudio needs to rebuffer and reprocess the audio. And furthermore, there's no reason why that process can't be bypassed.

              Comment


              • Originally posted by mugginz View Post
                Unfortunately there's no one perfect one size fits all solution so we can only choose from a pool of imperfect choices.
                That sounds like a niche to me.

                </enterprising>

                Too bad being a developer during the day eats up my hours of useful time.

                Comment


                • Originally posted by darkphoenix22 View Post
                  It has issues with about 10 kinds of middleware.

                  Again the problem with PulseAudio isn't the ideals. It's implementation. It breaks things as it meddles where it doesn't need to meddle.

                  There no reason why PulseAudio needs to rebuffer and reprocess the audio. And furthermore, there's no reason why that process can't be bypassed.
                  But there is a need to do this. Especially when you're got no hardware mixing. If Pulse doesn't do it then ALSA must dmix it. Either way, something has to. I personally find Pulses audio mixing sounds better as well.

                  Comment


                  • Originally posted by mugginz View Post
                    But there is a need to do this. Especially when you're got no hardware mixing. If Pulse doesn't do it then ALSA must dmix it. Either way, something has to. I personally find Pulses audio mixing sounds better as well.
                    Well dmix doesn't cause nearly as many problems as PulseAudio. PulseAudio is just too invasive. It does way too much. Probably the best course of action with PulseAudio is to split the project and repartition it out.

                    Comment


                    • Originally posted by p0larity View Post
                      Is there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?
                      A real future oriented game engine, not this bristle-work called Source... <.=.<

                      Comment

                      Working...
                      X