Announcement

Collapse
No announcement yet.

Frayed Knights for Linux - a maybe

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

  • #16
    Originally posted by Svartalf View Post
    Considering that you can target OSS and get most of the sound APIs,.

    ARRRGH!!!!
    /bang head against brickwall
    OSS Emulation has too many issues with hanging devices resulting in the sound device blocked after first call. This has been a long outstanding bug and one only has to google "/dev/dsp1: Device or resource busy" too see the long list of hits and what a truely huge PITA it is. (Just ask any teamspeak user....)

    This is one example where a depreciated interface should be left dead. ALSA has replaced it since 2003 in the kernel. The number of systems still running native OSS is dwarfed by systems running ALSA. Even when OSS was the "defecto standard" in the 2.4 kernel, most major distro's opted to use ALSA with the one long outstanding exception being at the time Redhat.

    Comment


    • #17
      Originally posted by deanjo View Post
      ARRRGH!!!!
      /bang head against brickwall
      Try a little harder- you've not put a hole in it yet...

      The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

      Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

      Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.

      Comment


      • #18
        Originally posted by Svartalf View Post
        Try a little harder- you've not put a hole in it yet...

        The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

        Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

        Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.

        I totally agree that ALSA can be a pain to code for but when done right it works and is stable. ALSA really has to cleanup and add some GOOD documentation. OpenAL needs some loving attention too. Developers have to start embracing it as will eventually ease the pain of porting. Right now IMHO there are too many projects out there that do too many overlapping jobs, many of which are depreciated or are developed at a snails pace. It's time some of these projects are axxed all together and those resources pooled together into a larger, more complete solution. Compiz / Beryl saw the light and came to their senses, if only more projects would follow their lead.

        This is where LSB should be pushed and embraced and refined. ALSA is currently being evaluated for inclusion in the next version of LSB.
        http://refspecs.linux-foundation.org...Use/book1.html
        Last edited by deanjo; 05-28-2008, 01:02 AM.

        Comment


        • #19
          Originally posted by Kano View Post
          I think some publishers don't know when they compile their games maybe on Debian etch it will run in most cases on everything newer, but now the other way around. Also you don't need to compile everything statically, as you can use a wrapper script that sets LD_LIBRARY_PATH to use the libs provided with the game.
          Which is what most commercial Linux games do, anyway, just see NWN's 'nwn' launcher script, or UT2K*, or UT99, etc.

          Comment


          • #20
            Originally posted by Svartalf View Post
            Try a little harder- you've not put a hole in it yet...

            The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

            Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

            Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.
            Sound on Linux is still its Achilles ankle in regards to Multimedia and gaming. If, and only if Pulse Audio picks up and really becomes the kind of framework that GTK or QT are for X11 on Linux (doing the low level windowing, etc; even wrapping OpenGL in X11, for instance, with GLX and such, but for OpenAL in this case), things could start happening. A HAL and common framework like PA could become, would mean that ALSA would only have to worry about the drivers and some libraries, in the way Xorg works and if no driver is found, PA would use a null device (to keep things from stop working). I know ALSA is much more capable than OSS, I also know it is much more Complex, and thus "harder" to code for, but so is "bare" X11. That's why I tend of think of things in the X11-WM/DE paradigm applied to sound infrastructure and architecture.

            Will ALSA/PA become what they seem could be the logical evolution? One can only guess, sit tight and wait.

            Comment


            • #21
              Originally posted by Thetargos View Post
              Which is what most commercial Linux games do, anyway, just see NWN's 'nwn' launcher script, or UT2K*, or UT99, etc.
              Which is also why people now have to go start hacking the startup scripts to get the games to run on newer distro's. NWN for example is broke on most modern distro's to prevent it using the SDL libraries that shipped with the game. Let it use the systems libraries and all is OK again.

              Comment


              • #22
                Originally posted by deanjo View Post
                Which is also why people now have to go start hacking the startup scripts to get the games to run on newer distro's. NWN for example is broke on most modern distro's to prevent it using the SDL libraries that shipped with the game. Let it use the systems libraries and all is OK again.
                Not necessarily true. I had a case recently where the version of SDL shipping with Dark Horizons:Lore Invasion wouldn't run for some distros, the system provided one wouldn't run either. The solution was for me to package the SDL that I was using in Kubuntu 7.10 & for people of 4 distros I know of to use the shell script to correct the issue.

                Comment


                • #23
                  Originally posted by SlackerTD View Post
                  Not necessarily true. I had a case recently where the version of SDL shipping with Dark Horizons:Lore Invasion wouldn't run for some distros, the system provided one wouldn't run either. The solution was for me to package the SDL that I was using in Kubuntu 7.10 & for people of 4 distros I know of to use the shell script to correct the issue.
                  I didn't say it was the only solution, I was just using what had to be done for NWN to work on newer distros as an example.

                  Comment


                  • #24
                    Originally posted by deanjo View Post
                    This is where LSB should be pushed and embraced and refined. ALSA is currently being evaluated for inclusion in the next version of LSB.
                    http://refspecs.linux-foundation.org...Use/book1.html
                    I dont agree with LSB at all... Not even a little bit..

                    The problem with LSB is that it literally prevents innovation in every possible way. One way of going things may not be the best way. So if I develop a different way of doing that same thing, it may not be compatible, but eventually it may well replace the old way... This is what is commonly known as progress. Better methods replacing deprecated methods. LSB completely eliminates that possibility... Innovation dies with LSB...

                    Just look at the package manager that LSB requires and then you'll knwo exactly what I'm talking about.

                    Comment


                    • #25
                      Originally posted by duby229 View Post
                      I dont agree with LSB at all... Not even a little bit..

                      The problem with LSB is that it literally prevents innovation in every possible way. One way of going things may not be the best way. So if I develop a different way of doing that same thing, it may not be compatible, but eventually it may well replace the old way... This is what is commonly known as progress. Better methods replacing deprecated methods. LSB completely eliminates that possibility... Innovation dies with LSB...

                      Just look at the package manager that LSB requires and then you'll knwo exactly what I'm talking about.
                      The LSB does not limit innovation at all, but ensures that a common solution is available. I assume your griping about RPM being package standard. LSB can still be adhered too with debs when alien is used.

                      Again, if there is a better solution to an issue the lsb can be changed and amended, thus why I said it has to be refined. LSB should be viewed as a common set of required tools to maintain cross compatibility.
                      Last edited by deanjo; 05-28-2008, 10:18 AM.

                      Comment


                      • #26
                        But then you have the problem that if LSB can be changed at will (which it cant be), then what is the point? In that case it has no value at all becouse it serves no purpose.

                        Additionally your assuming that all folks will be using RPM, or Apt. The fact is that is not at all the case. Your also assuming that all people will be running xorg. Your assuming that all people will be running alsa. Your assuming that all people will be running apache. Your assuming that all people will be running udev. Ands many,many,many,many more assumptions that all prove to be simply false.

                        I'm sorry but it just doesn't work that way. If you change one of these LSB required components then you will break compatibility. But if I'm running a server I dont need xorg installed. I may choose to use a modern version of OSS instead of the deprecated version that is in the kernel. I may well opt to use a framebuffer device for the display if I am using my system as a PVR. And there are many,many,many,many more examples then just these where LSB simply does not work.

                        I'd even go so far as to say that LSB will only work for less the 0.000001% of the entire linux community, and even in that extremely rare case it will be entirely deprecated and unsupported in less then three days of use.

                        The fact of the matter is that LSB does --not-- ensure compatibility. It actually breaks compatibility in the simple fact that LSB makes it entirely impossible for most folks to do what they want to do. Not to mention that it makes replacing deprecated components impossible.

                        The moment you replace RPM you've broken compatibility. The moment you've replaced glibc, or udev, or hal, or binutils, or xorg, or alsa you have broken compatibility. In order to maintain compatibility you will permanently be stuck with the packages and versions of those packages that you've chosen. This is exactly what LSB does, and it is exactly what is wrong with it...

                        Comment


                        • #27
                          Originally posted by deanjo View Post
                          I didn't say it was the only solution, I was just using what had to be done for NWN to work on newer distros as an example.
                          For example, other vendors provide dynamic link versions of their titles for dealing with the odd problem or an ABI breakage- but provide statically linked binaries (yes, it's big, but then the result ends up being consistent across a HUGE range of distributions and versions of the same...) and only get broken when something dramatic happens in the glibc ABI or the Linux kernel hooks. Loki's stuff ran until the ABI got changed sufficiently enough to break them all to hell.

                          Comment


                          • #28
                            Originally posted by deanjo View Post
                            The LSB does not limit innovation at all, but ensures that a common solution is available. I assume your griping about RPM being package standard. LSB can still be adhered too with debs when alien is used.

                            Again, if there is a better solution to an issue the lsb can be changed and amended, thus why I said it has to be refined. LSB should be viewed as a common set of required tools to maintain cross compatibility.
                            But Alien's a band-aid on the problem. You see, the standardization was a good idea- LSB is just poor execution that only the RPM based distributions can actually follow. In fact, I think SuSE and Red Hat are the only ones that slavishly follow the thing, being that they're the main ones for coming up with it. Debian can't really follow it that closely because it's really, really Red Hat centric if you read it closely. Worse, RPM, internally does all kinds of goofy-loopy things. Which version do you want to support and realize that the packaging tools vary on macros, etc. so you're not going to get consistent results there either.

                            LSB's a poor execution to a nice idea. Don't know if you CAN get that execution any better though without ditching the notion of packaging being controlled by the spec. You should specify ABI's and API's provided and a certain specific range for this version of the base standard. Until you get to that stage, it's just not going to work. Most of the problems with binaries, etc. is because we can't keep consistent across distros with ABIs (we didn't have a consistent C++ ABI until recently, for example...) and the lot. Not about where binaries should be put, not about directory structures, and not about what packaging manager you're using. LSB specifies all of it. You might as well be using Red Hat at that point.

                            Comment

                            Working...
                            X