Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • So many posts on the subject of pulseaudio as if that's the main barrier stoping games coming to linux. It doesn't make sense. Nowadays pulseaudio works. It didn't work properly 2 years ago thats true, but it does now so why not move on to other subjects? And besides, if the gamer wants to play a game he'll find a way. You can be sure of that. I remember the good old DOS days when you had to edit your config.sys and autoexec.bat to free the 590Kb of base memory that a certain game required to run. Or even having to install that VESA VBE stuff to get decent performance.

    People who say that there will never be comercial games on linux because users will probably have to configure their system to make it work clearly never played a PC game in the 1990's. Even on windows not everything works straight out of the box everytime. The gamer is a very resourceful dude and the linux gamer probably even more. Believe in the gamer and fear not

    Comment


    • Like I said, in my tests, which were performed a few months ago, half of the games didn't work under PulseAudio. The games/emulators which were ports faired the worst. Nearly all of them needed configuration, if they didn't require you to remove PulseAudio.

      Linux gaming will need to compete with console gaming, where you just insert a disc and have the game play. Having to configure stuff is acceptable for a server, but I can't expect my dad or my 10-year-old brother to reconfigure their Linux audio setup so the sound won't skip.

      Comment


      • Originally posted by Kano View Post
        As most games use openal and that supports alsa or some other older games use sdl as abstraction layer why does the api matter? You can compile newer libs or just use the prebuild ones which come with the distro (a bit compilicated on 64 maybe). if the names are different just use a few symlinks. For other games like et there are already alsa wrappers - needed for maverick anyway.
        I'd hesitate to say that "most games use OpenAL" Kano. And not everything else uses SDL/SDL_mixer (nor do I recommend that one attempt to do so unless they're needing something simple- or have no other options...). There is also FMOD, IrrKlang, and at least Miles as well.

        As for whether it's acceptable or not, I'd have to say that ALSA doesnt' QUITE live up to it's stated goals, back from when they'd made the decision to move it into the kernel. Amongst it's claimed things, it was supposed to remove the need for things like ESD, Arts, and PulseAudio from basic configuration- you were going to be able to have multiple apps just use the sound subsystem directly and not worry about the blocking behavior OSS provided for sound. To the best of my recollection, that was one of it's selling points back when it was introduced- and we're still adding things like PulseAudio on top of it to accomplish this task.

        Does that mean we need to rip it out and put OSS back in? I can't say either way. Something DOES need to be done though- and PA and the others aren't really the solution people keep making them out to be. Haven't been to date- and re-inventing the wheel in that space won't get you any closer no matter how "clean" the code is. (And stating things like "striving for lower latency than with raw ALSA" doesn't impress me in the slightest...you're always going to increase latency with the methods being used there. How bad you make it and how cleaner you can make coding for it is all you can control there.) What we've got going on presents something of a problem for some classes of situations- why gloss over it when we're supposed to be about technical excellence in this community, first and foremost?

        Comment


        • Originally posted by devius View Post
          So many posts on the subject of pulseaudio as if that's the main barrier stoping games coming to linux. It doesn't make sense. Nowadays pulseaudio works. It didn't work properly 2 years ago thats true, but it does now so why not move on to other subjects? And besides, if the gamer wants to play a game he'll find a way. You can be sure of that. I remember the good old DOS days when you had to edit your config.sys and autoexec.bat to free the 590Kb of base memory that a certain game required to run. Or even having to install that VESA VBE stuff to get decent performance.

          People who say that there will never be comercial games on linux because users will probably have to configure their system to make it work clearly never played a PC game in the 1990's. Even on windows not everything works straight out of the box everytime. The gamer is a very resourceful dude and the linux gamer probably even more. Believe in the gamer and fear not
          I agree. Honestly, if I install a game on linux and it runs without any configuration on my part, I would be very, very surprised. I am pretty sure, that any linux user is already perfectly comfortable with having to poke things to get them to work, as long as there is readable documentation or forums.

          Back in the day, when the Doom3 ALSA support landed, I had to fiddle with the audio buffer size to not have skipping sound, while using the dmix plugin. Fortunately a too-high setting sounded differently from a too-low setting, so I could do a simple binary search . Then, there were a few times when I had to patch a binary using a hex editor; one of which - because the game was dead-set on requesting anti-aliased lines, which my videocard's drivers didn't support.

          Besides, you will never ever be able to support every linux configuration under the sun. We love doing things our way and being different, that's part of the fun. Just supporting the latest ubuntu LTS is enough - your game will "just work" on most computers and everybody else probably knows what they're doing and won't mind editing some configuration.

          Just get your game out - we'll get it to run, then we'll tell everybody how we got it to run. Perhaps you could release a patch to support the odd corner-case we hit, while trying to run it. Or you could decide it's not worth it - that's still cool. As long as I have a game.

          Comment


          • Originally posted by Svartalf View Post
            ....Does that mean we need to rip it out and put OSS back in? I can't say either way. Something DOES need to be done though- and PA and the others aren't really the solution people keep making them out to be. Haven't been to date- and re-inventing the wheel in that space won't get you any closer no matter how "clean" the code is. (And stating things like "striving for lower latency than with raw ALSA" doesn't impress me in the slightest...you're always going to increase latency with the methods being used there. How bad you make it and how cleaner you can make coding for it is all you can control there.) What we've got going on presents something of a problem for some classes of situations- why gloss over it when we're supposed to be about technical excellence in this community, first and foremost?
            On the whole, I'd have to say there's a fair bit to like about PulseAudio. Although when you're using a package that doesn't work well with it then all of a sudden your opinion can change

            At least these days, for the most part, quite a lot of software will work with it. Then you do get to enjoy the non-blocking, per-app volume, on the fly re-routing of audio, etc. As a user of bluetooth headsets for skype, I can say it's been the best thing since sliced bread. While if you were happy to edit config files and waste countless amounts of time fiddling, you could sometimes get skype and bluetooth to be happy with ALSA and friends, but it was a bit touch and go.

            Even as a user who has software that isn't happy with native PA like Blender, often you can ask you're software to use ALSA or ESD output instead which can get things happy. Not perfect, but when compared to pre-PA days, nothing really new there.

            I've been using Linux for many years. Been using it as a replacement for Windows since the Mandrake 9.0 days. I've usually had to massage each install in that time in order to get it to do the normal things people expect of a computer and audio playback has always been one of those areas that had to be played with. Things began to mature to an acceptable point just before Pulse was released but was still far from a perfect, install and go experience. Then PA comes along promising the world but delivered much heart ache and breakage. Recently PA has matured to a point were it now out delivers a straight ALSA install and for a lot of software it's complete bliss in comparison to what came before it.

            There is still some problematic software out there though unfortunately. And it's not surprising those projects don't work well with it when you have the developers making comments along the lines of "works with ALSA, not with Pulse. Pulse sux and it's only Pulse's fault." With that kind of an attitude it's no wonder their software doesn't play well with it. Even if it requires some re-architecting of their app it'd be nice if they'd have a fair dinkum go at fixing what they can instead of calling for yet another major upset and re-architecting of the Linux audio stack instead.

            I'm not so sure the Linux ecosystem would survive unscathed if everyone had to got through another two year period of major breakage and mayhem in the audio system such as that when Pulse was adopted. Now that it's mostly working I'd be calling for a gradual perfection of what we have, not another round of 'throw it out and start from scratch'. If people want to see OSS4 come along and oust PulseAudio and ALSA then please, only once it's feature complete, tested, robust and compatible. Not before.

            Comment


            • There is still some problematic software out there though unfortunately. And it's not surprising those projects don't work well with it when you have the developers making comments along the lines of "works with ALSA, not with Pulse. Pulse sux and it's only Pulse's fault." With that kind of an attitude it's no wonder their software doesn't play well with it. Even if it requires some re-architecting of their app it'd be nice if they'd have a fair dinkum go at fixing what they can instead of calling for yet another major upset and re-architecting of the Linux audio stack instead.
              The question is, why should they care. If it requires X hours of work for things they don't use nor care about, where's the motivation?
              Also, your quoted comment doesn't ask for another major upset, it asks for the removal of the most recent upset.

              Comment


              • Once again, I'm not in favour of immediately removing ALSA in favour of OSSv4. I'm only in favour of pushing it into the repos of distros so it can be developed further.

                I do believe Pulse needs to be removed immediately because it does break games and it does break programs. Recoding everything to be tolerate of a wrapper is not an option. Removing the wrapper and integrating its functionality into the core sound API is the only way to go.

                If this can be done with ALSA, sure let's stick with ALSA. But I'm not sure if it can.

                Comment


                • Originally posted by Mo6eB View Post
                  Besides, you will never ever be able to support every linux configuration under the sun. We love doing things our way and being different, that's part of the fun. Just supporting the latest ubuntu LTS is enough - your game will "just work" on most computers and everybody else probably knows what they're doing and won't mind editing some configuration.
                  Careful there. Ubuntu LTS isn't the whole sum of Linux. You've just tripped yourself up if you're trying to provide a commercial game or similar. No, you're not going to be able to support every system- but your thinking you're espousing isn't the answer either.

                  Just get your game out - we'll get it to run, then we'll tell everybody how we got it to run. Perhaps you could release a patch to support the odd corner-case we hit, while trying to run it. Or you could decide it's not worth it - that's still cool. As long as I have a game.
                  Ah... But what if you've pinned your libc ABI versioning and something like Pulse pulls in one of your forbidden symbols? You end up with a game that only the people that don't have that version of Pulse in their system, and so on and so forth. I know about this one from professional experience. And it can happen with distributions other than Ubuntu- and not just Gentoo or Arch either.

                  More to the point I'm getting to here, the BULK of the potential userspace aren't hardcore tech geeks. They just want to have it drop in and work. Heck, I don't have the time to tinker around like you're implying or to wait for someone else to do it for me- it'd better mostly work out of box. And with PulseAudio, it DOESN'T. Raw ALSA or OSS often does better with things than PA does- now the claims of poor implementation and execution on the part of the distributions (Ubuntu, by the by, was one of the guilty parties there...) may be legit, but it implies there's some complexity we don't need.

                  AND it does inject latencies in the mix that aren't there with the lowe level stuff. Seriously. You're adding a dispatch layer on TOP of everything else to support per-application level mixing of sounds and network redirection. It's going to add latency in there that isn't there with the raw, low-level stuff.

                  Comment


                  • Originally posted by curaga View Post
                    Also, your quoted comment doesn't ask for another major upset, it asks for the removal of the most recent upset.
                    Or at least a correction of the previous one so you don't need the most recent one...

                    We're looking at approximately 12+ years (yes...) of trying to get it right and missing the mark on sound here. Three differing failed attempts (including OSS, when you get to brass tacks here...) to get it right on Sound. At least with 3D, you've largely had the same API interfaces for things, back from when Utah-GLX was the thing, all the way to now. With sound, you've had this hodge-podge of things that offer sort of OSS interfaces, sort of ALSA interfaces, etc.

                    Comment


                    • Originally posted by darkphoenix22 View Post
                      If this can be done with ALSA, sure let's stick with ALSA. But I'm not sure if it can.
                      It's almost been done with ALSA, so I'm not wholly sure WHY we needed PulseAudio to begin with- unless the DMix stuff's hopelessly broken for whatever reason (which implies a re-work of that, and not doing yet another layer on top of things...).

                      Comment


                      • I would like to see an analysis on how much work it would take to get ALSA to support these features.

                        The OSS dev has been pretty clear about what needs to be done and how much it would cost:
                        http://4front-tech.com/hannublog/?m=200908

                        I would be in favour of whatever economically costs less.

                        Comment


                        • Originally posted by darkphoenix22 View Post
                          I would like to see an analysis on how much work it would take to get ALSA to support these features.
                          As would I.

                          The OSS dev has been pretty clear about what needs to be done and how much it would cost:
                          http://4front-tech.com/hannublog/?m=200908

                          I would be in favour of whatever economically costs less.
                          As would I- however, there's politics involved (as there were (it wasn't all technical reasons motivating the move of OSS vs ALSA back then...there was a LOT of politics involved from at least one of the mainline distributions of the time with the move...) and Hannu's not really popular with the crowd that is in charge with the Linux Kernel right at the moment...) so you need to factor that into your thinking as well.

                          Comment


                          • I just don't want to drive away game developers because of Linux's mess of a sound system.

                            I'm tired of politics driving Desktop Linux development.

                            Comment


                            • I still don't know why it's a mess.

                              Mixing works perfectly here, with as many streams as you want, at different frequencies, with binary crap such as Adobe Flash, and anything I've ever thrown at it.

                              If it doesn't work for someone, then it's a buggy driver and you need to file a bug.

                              The per-app volume is a thing that sometimes works and sometimes not. I agree that it should be fixed.

                              Other than this, I see NO advantage in switching back to OSS.

                              Comment


                              • Because on many distributions, especially the popular ones, games will be broken out of the box due the latency introduced by wrappers and abstraction.

                                Comment

                                Working...
                                X