Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • Originally posted by darkphoenix22 View Post
    Hey, I helped out 3 people personally on LinuxQuestions.org fix their audio problems by removing PulseAudio.

    It's also recommended as a good first step after an install on AVSForums.
    For those having problems with specific implementations of Pulse.

    What do you recommend for the people having problems with ALSA?

    Comment


    • Originally posted by mugginz View Post
      No less so than Pulse
      Do I really need to quote Svartalf again?

      http://www.phoronix.com/forums/showt...695#post132695

      Comment


      • Originally posted by darkphoenix22 View Post
        Do I really need to quote Svartalf again?

        http://www.phoronix.com/forums/showt...695#post132695
        So he's unable to implement playback as well as the Doom3 demo has?

        Comment


        • Originally posted by mugginz View Post
          For those having problems with specific implementations of Pulse.

          What do you recommend for the people having problems with ALSA?
          Most of their problems seem to be solved by using a decent mixer GUI, which Gnome seems to sorely lack. Bluetooth is the exception, admittingly. https://bugs.launchpad.net/infinityos/+bug/552831

          Comment


          • Originally posted by mugginz View Post
            So he's unable to implement playback as well as the Doom3 demo has?
            Why don't you ask him yourself?

            Comment


            • Originally posted by darkphoenix22 View Post
              Why don't you ask him yourself?
              I would imagine he'll end up reading this thread and will respond when he does.

              Comment


              • Originally posted by pingufunkybeat View Post
                Steam is not coming to Linux,
                Well this thread is about it and I didn't create it so I don't know what to tell you about that. You might be lost since you're discussing something that you don't think will arrive.


                Originally posted by pingufunkybeat View Post
                You really think that this is some sort of battle where PA has to "win", and we will get Steam as a reward?
                Did I say that? No I didn't. The discussion of OSS4 vs ALSA and the problems of PA was a discussion started long before I came a long I added my point of view and that was that.

                Comment


                • The only time Pulse has given me problems is when running certain games on Wine.. Unreal Tournament 3 immediately comes to mind.. Running OpenSuse 11.2 and Creative audio hardware works very well overall.

                  Comment


                  • Impartial 3rd party take on Linux audio:
                    The audio situation is another major obstacle to game development on Linux. It’s 2010; audio is a solved problem. And yet on Linux, it’s shocking that you cannot count on something as simple as non-streaming playback, never mind any kind of processing (which most games are wont to do!) There are a variety of standards (ALSA, OSS, PulseAudio, Phonon, …) — which one to choose? Each standard has different problems on different machines. For a given standard, some drivers are buggy and poorly configured by default, while others do horrible thinks like block on open when another process opened the device. This is all another way of saying that there are no audio standards. What is a developer to do?

                    “But doesn’t OpenAL hide all the mess behind a single stable API? Ideally you’d write the audio code once in OpenAL and then walk away.” This isn’t how it happens in practice, because the fact of the matter is that the mess is still there. Simply wrapping another software layer around the underlying problem doesn’t make it go away. Using OpenAL for audio doesn’t all-of-a-sudden mean I can count on anything runtime-behavior-wise. I write my code in OpenAL (rather than having to write directly in ALSA, PulseAudio, etc), but at runtime I still need to make choices — for example, by saying which underlying audio layer I want to use — and different people’s machine/lib/driver combos will do different things. Simply using the local machine’s default audio device doesn’t guarantee anything about what’s going to work and what doesn’t, and a game needs guarantees in order to work correctly. The audio situation is quite horrible I’m afraid.
                    From: http://www.hemispheregames.com/2010/...ortem-part-23/

                    Good article, lots of good criticisms, sadly it will be ignored or dismissed rather than fixing the underlying issues.

                    Comment


                    • The other parts of that article are also well worth the read.

                      I should purchase Osmos these days, but I'm not even playing the Humble Bundle stuff I purchased not so long ago.....

                      Comment


                      • Originally posted by yogi_berra View Post
                        Impartial 3rd party take on Linux audio:

                        From: http://www.hemispheregames.com/2010/...ortem-part-23/

                        Good article, lots of good criticisms, sadly it will be ignored or dismissed rather than fixing the underlying issues.
                        Matches 100% my own experience. This article is really good.

                        Comment


                        • Originally posted by yogi_berra View Post
                          Impartial 3rd party take on Linux audio:

                          From: http://www.hemispheregames.com/2010/...ortem-part-23/

                          Good article, lots of good criticisms, sadly it will be ignored or dismissed rather than fixing the underlying issues.
                          The old song. Instead of solving problems with better design moan about them and push the blame on others.

                          Comment


                          • Having everything in a magical one-size-fits-all solution is not good design. Hell it's not Unix.

                            Comment


                            • It's not a one-size-fits-all solution. It's actually very Unix like in that the code dealing with card switching is placed at the exact right location. This kind of code is wrong in drivers (code-duplication smells, each driver has to implement it) as well as in applications (code-duplication smells, each app has to implement it). The non-Unix solution would be to scatter this code all over the place instead of tasking a single unit with handling this transparently in both directions.

                              Have you even an idea about software design? Looks like not.

                              Comment


                              • Again, it doesn't separate out functions like the per-app volume controls, the software mixing, and the device switching.

                                Each of these functions would be better handled as separate entities, rather than in one whole.

                                Comment

                                Working...
                                X