Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • Originally posted by drag View Post
    There are lots of things that could cause that. For example: It's a shell script or other interpreted language and the person that wrote it hardcoded it to a interpreter that can be moved, instead of using the 'env' command to locate it for them.




    You can still use a terminal. The user can just find the executable in /opt/$app-name/bin/ and if they would like they can add it to their path accordingly. A guy used to using a terminal for stuff should not have a problem figuring that out.
    That's a royal pain in the ass, and that results in an unusable terminal such as in Windows. Windows also has a PATH variable, so in theory you could fix it there, too.
    The thing that sucks about $PATH is that it can be anything. I would avoid trying to write to /bin/ or /usr/bin/ and things like /usr/games/bin is very distro-specific. Symbolic link to /usr/local/bin/ is probably the best place, but even then it's not 100%.
    I'd go for /usr/local/bin/, too. I'd use /opt/bin/, but no distro includes that in its PATH variable.

    Comment


    • Originally posted by drag View Post
      Yeah. No.

      You have it backwards. The minority of people run proprietary drivers on Linux.

      In, general, if you combined the amount of people using ATI and Nvidia into one big pool you will not come close to the number of people using integrated Intel graphics.
      That's true, but Intel drivers offer OpenGL 2 through Mesa. And their hardware doesn't support anything more. So, yeah, game companies can't let go of the OpenGL 2 renderer. They can't let go of DirectX 9 on Windows either.

      Comment


      • Originally posted by drag View Post
        As far as PA goes...

        You NEED to implement software mixing in the audio stack.

        This is NOT optional. If you want a modern OS with any decent hardware support and performance then you are ABSOLUTELY going to have to implement a software mixer.

        You do NOT have a choice in the matter. It's a bold faced requirement to have a minimally functional audio stack.

        And it's going to add latency.

        It does not matter if you do it in the kernel or in dmix or if you do it in PA. The effect is the same. There is no magic latency-reduction that you get by implementing mixing service as a kernel module or as a userspace daemon.
        I will implement PulseAudio as soon as it has been demonstrated to work with existing code. As is, it breaks a few programs that are included with my distribution.

        The solution provided by the PulseAudio developers, the suggestion that all existing code and drivers should be rewritten to tolerate the limitations and latency scheme of PulseAudio is simply unacceptable. This is, bottom-line, an unobtainable goal.

        The fact that all code can't be rewritten to work with PulseAudio is further demonstrated by the fact things are still broken when using PulseAudio. These very applications worked completely under bare ALSA in my testing and OSSv4 under my friend's testing.

        Games and PulseAudio mix like water and this is not because of bad or improper code. This is because of broken architecture and design.

        Comment


        • Edit: Games and PulseAudio mix like water and oil and this is not because of bad or improper code. This is because of broken architecture and design.

          Perhaps, with an another, simpler audio API, a wrapper would work. But I do not believe this possible with PulseAudio because of design. Not all applications and games can be satisfied with only the Pulse-safe subset of ALSA. PulseAudio provides no solution to this problem. Libsyndey has not either.

          Comment


          • Originally posted by darkphoenix22 View Post
            It depends on how the application implements sound. If it uses sound for timing, it's toast with PulseAudio due to the higher latency introduced by the wrapper/buffer. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.
            I don't see how a wrapper increases latency, since it's simply said just abstracting APIs. No buffering of any audio. Any buffers are residing in the game's own mixer, which would be present in Windows versions, too.

            And from what I've noticed, the userland mixer introduced in Windows Vista didn't hurt latency noticably either, compared to XP. Unless Pulseaudio is completely retarded, it'll work.

            Comment


            • Originally posted by drag View Post
              In, general, if you combined the amount of people using ATI and Nvidia into one big pool you will not come close to the number of people using integrated Intel graphics.
              Maybe it's just my practical idealism, but I figure that anyone that may consider playing the Linux ports of the Source games would probably own or procure decent hardware.

              And even if not, since the Mac environment presents same the integrated Intel vs. ATi/NVidia rift, it's safe to assume that the Source ports will feature different GL render paths.

              Comment


              • Originally posted by Tomservo View Post
                And from what I've noticed, the userland mixer introduced in Windows Vista didn't hurt latency noticably either, compared to XP. Unless Pulseaudio is completely retarded, it'll work.
                And this is the problem. PulseAudio doesn't allow access to all the APIs needed in ALSA in gaming for timing. Games and programs that are not programed to be tolerate of a bare buffer instead of direct hardware access will fail when using PulseAudio. As this is a common programming technique for games on every operating system, game developers are not going to change their development methodology to suit the needs of PulseAudio. They give up and will look elsewhere.

                For better or for worse, PulseAudio is a demonstrated barrier for programming games on Linux. Changing how every games and game library is programmed is not the answer as this is a solution can never be completed.

                An incomplete wrapper like PulseAudio will never work with games that require direct sound hardware access (even if it is through a library). And sadly, this is the majority of games.

                Comment


                • Simply put, ALSA is too complicated and expansive of an API to allow for a wrapper that will work for all situations. ALSA was never designed to be used with a wrapper and will never work completely with a wrapper. Period.

                  Comment


                  • Originally posted by darkphoenix22 View Post
                    Simply put, ALSA is too complicated and expansive of an API to allow for a wrapper that will work for all situations. ALSA was never designed to be used with a wrapper and will never work completely with a wrapper. Period.
                    Ugh, I had to join and say something. After thumbing through this entire thread, I cannot see a single supporting factor against ALSA in any of your claims. I've had -perfect- working dmix configurations with ALSA since a year or two after it was introduced (I cannot remember the specific timeframe), and now sound configuration for me involves plopping a simple asound.conf into /etc/.

                    Code:
                    pcm.snd_card {
                         type hw
                         card 1
                    }
                    
                    pcm.dmix {
                         type dmix
                            ipc_key 1024
                            ipc_key_add_uid false
                            ipc_perm 0660
                            slave {
                                    pcm snd_card # see below
                                    rate 48000
                                    channels 2
                            }
                         }
                    
                    
                    pcm.duplex {
                        type asym
                        playback.pcm "dmix"  # just pass to dmix.
                    #    capture.pcm "usbcam" # or whatever capture device
                    }
                    
                    pcm.!default {
                         type plug
                         slave.pcm "duplex"
                    }
                    
                    pcm.dsp "duplex"
                    pcm.dsp1 "duplex"
                    Mixing problem solved. PulseAudio, OpenAL, WHATEVER will now mix audio using DMIX from that point onward (as long as they're configured to use ALSA), which is more or less what the majority of users require. In many cases this type of default configuration is provided by the distribution maintainer.

                    Your claims for Per-App volume control being "beyond" ALSA's capability are also pretty silly. All ALSA needs to do is automagically add a mixer control for every application access. The difficulty of adding this functionality is really in the implementation, not for you or I or -anyone- outside of the ALSA project to comment on.

                    Before even that, I don't see the critical need for such a feature. I don't have a million volume knobs on my amp for each input, I have one: VOLUME. That's all I need, and all I really care about when it comes to it. Most applications that need such control have their own volume configuration anyway- Don't believe me? Look at almost any PC game or media player out there. They all have their own volume control. This kind of useless feature is what creates bloat and turns our Linux sound experience into some obscure sound "server".

                    Your advocacy for OSSv4 is also really unjustified- it is incomplete, has none of the more advanced features ALSA has, and most importantly isn't proven on the desktop. It cannot possibly be considered as a viable replacement until it provides 100% of the basic functionality that all users need out-of-box, and doesn't get in the way of other (currently working) solutions. It currently fails both conditions.

                    Better idea - Fix ALSA's real problems. How about implementing the holy grail of sound - Mixed DDL? Fix the (in most cases minor) performance issues and get DMIX + the A52 encoder playing nice together, that'll make alot of people happy. Currently some implementations like that cannot be pipelined as expected, which is (as far as I know) ALSA's only real limitations, and can most certainly be fixed through the normal bug chasing or reimplementation of those features.

                    Comment


                    • Originally posted by kazetsukai View Post
                      Your advocacy for OSSv4 is also really unjustified- it is incomplete, has none of the more advanced features ALSA has, and most importantly isn't proven on the desktop. It cannot possibly be considered as a viable replacement until it provides 100% of the basic functionality that all users need out-of-box, and doesn't get in the way of other (currently working) solutions. It currently fails both conditions.

                      Better idea - Fix ALSA's real problems. How about implementing the holy grail of sound - Mixed DDL? Fix the (in most cases minor) performance issues and get DMIX + the A52 encoder playing nice together, that'll make alot of people happy. Currently some implementations like that cannot be pipelined as expected, which is (as far as I know) ALSA's only real limitations, and can most certainly be fixed through the normal bug chasing or reimplementation of those features.
                      Then let's fix ALSA.

                      If the choice is between fixing ALSA and switching to OSSv4, I'm in favour of what will take less work and cost less money.

                      Comment


                      • In the end, our decision should not be based not politics or perceived technological superiority. It should be solely based on which path is cheaper and easier to take to reach our goal. This goal is to have a default sound API situable for game development on Linux, without hacks or compromises like PulseAudio.

                        The path we take should be left to pure economics.

                        Comment


                        • Edit:

                          In the end, our decision should not be based on politics or perceived technological superiority. It should be solely based on which path is cheaper and easier to take to reach our goal.

                          This goal is to have a default sound API suitable for game development on Linux, without hacks or compromises like PulseAudio, while being able to be extended to meet the needs of future developers and users.

                          The path we take should be left to pure economics.

                          Comment


                          • Originally posted by darkphoenix22 View Post
                            Edit:

                            In the end, our decision should not be based on politics or perceived technological superiority. It should be solely based on which path is cheaper and easier to take to reach our goal.

                            This goal is to have a default sound API suitable for game development on Linux, without hacks or compromises like PulseAudio, while being able to be extended to meet the needs of future developers and users.

                            The path we take should be left to pure economics.
                            The cheapest solution is rarely, at best, the best long-term solution for any problem.

                            Comment


                            • The cheapest solution right now is to remove PulseAudio and let ALSA be.

                              What I mean by pure economics is what will cost Linux less in the long run in terms of work? Extending ALSA or improving and testing OSSv4, a much simpler API?

                              Whatever is economically cheaper in terms of work and cost in the long run is the path I would like to take.

                              Comment


                              • Can you point me to a source which compares the OSS and ALSA APIs from an application developer POV?

                                You keep saying that ALSA is too complex and OSS is very easy, and I've kept asking you why you say this, and you haven't answered.

                                Are you a multimedia programmer? Have you written an ALSA and/or OSS backend? How do you know this?

                                Comment

                                Working...
                                X