Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • Most HDA Intel devices work for playback, the problem begins when somebody wants to use a mic. This often requires extra options or a bigger patch. Tested module overrides can easyly transfered into kernel/alsa patches.

    In the case of mic problems which are not directly solveable using module overrides i usually suggest using a small usb sound adapter - this works with every os. Also nice when you don't have got front audio connectors.

    @Svartalf

    Did you try to unload driver/apps using alsaconf instead of rebooting? I had curious effects here too, like when i tested audio via hdmi i had to remove power for my monitor - before audio was muted even when the osd showed full volume.

    Bluetooth devices heavyly depend on the software stack. Currently alsa can be used to setup those devices directly in the .asoundrc but with an older stack that does not always work reliable. Informer a special alsa module (snd-bt-sco) was used together with btsco (user space) - that basically worked better than the newer direct integration, but most likely using new user space tools should fix those issues. Compared to other headsets you just always have got a delay via bluetooth.

    Comment


    • I have to add that Bluetooth headsets are unreliable on any operating system in my experience. I ditched mine for a USB Headset, which works fine using plain ALSA. I just had to change the output in Xfce Mixer.

      Why again do we need a layer of abstraction made default to satisfy these edge cases? If a user needs Bluetooth audio, he is free to install PulseAudio. There is no need for it to be made default, especially if it breaks games.

      Comment


      • Originally posted by darkphoenix22 View Post
        I have to add that Bluetooth headsets are unreliable on any operating system in my experience.
        I found Windows to be quite nice with bluetooth headsets. I will say though that some of the cheaper bluetooth dongles come with some appalling software but the Microsoft native stuff is pretty good.

        Originally posted by darkphoenix22 View Post
        I ditched mine for a USB Headset, which works fine using plain ALSA. I just had to change the output in Xfce Mixer.
        How easily did you configure ALSA to play with your bluetooth headset?

        Originally posted by darkphoenix22 View Post
        Why again do we need a layer of abstraction made default to satisfy these edge cases? If a user needs Bluetooth audio, he is free to install PulseAudio. There is no need for it to be made default, especially if it breaks games.
        The sign of a mature system is the ability to deal with both mandatory as well as other non-core but nice features.

        Person A - "But I can't get sound to work with my bluetooth headset...."
        Person B - "Oh you're one of those strange people that want to do something that's not normal sound playback. Go read this FAQ and add that patch and edit these config files and then reboot. Now when you want to go back, edit this config and execute that shell command"

        Isn't it time to get past just providing the simplest of sound support and also allow people to be able to depend on other more modern things as well. Do we need to remain the "Soviet Era" of multimedia for ever?

        Comment


        • OK... So bluetooth is a edge case. (which it's not) (And my bluetooth headset is actually reliable in Linux.)

          So... even though users are already quite happily using Bluetooth for audio in OS X and in Windows 7 it's just not good enough for Linux to support it without swapping out audio subsystems.

          ------------------------


          Now lets look at USB headphones.

          How easy is it to deal with hotplugging audio devices with Alsa or OSSv4?

          I know that it basically is nothing but hell to deal with with just Alsa by itself. The idea that I would have to go back to managing multiple asoundrc files and shutting down applications and restarting them each time I want to plug my headphones in is completely unacceptable.


          I never used OSSv4 though.

          Say I am playing a video game and I want to use something like skype or other voip system to talk to people.

          What would I have to do in OSSv4 to make it so that when I plug in my USB headphones that the game continues to play through my speakers, but I can use the mic and headset to talk to my buddies?


          Say I am watching a movie on my laptop and my roomate gets all pissy about the noise. What would I have to do, using OSSv4, to change the default audio output from my speakers to the USB headset?

          Can I do this on the fly, or do I have to kill my movie first?

          Comment


          • @Svartalf

            Did you try to unload driver/apps using alsaconf instead of rebooting? I had curious effects here too, like when i tested audio via hdmi i had to remove power for my monitor - before audio was muted even when the osd showed full volume.

            It wasn't really happy until I rebooted about 1/2-2/3rds the time- so I just restart my machine that shouldn't otherwise need to be rebooted to get sound back (Not that I should HAVE to do what you've suggested, Kano, either...).

            This is the reason I'm even discussing any of this as much as anything else. We still don't have it solid like we think we do- for whatever reasons.

            Comment


            • Basically you don't need to change the default for every use case. Of course if want all sound redirected you can change the default in .asoundrd. That's basically needed for flash videos in the browser, i did not find an override option for that yet. VLC allows audio device switching on the fly without stopping the media - also nice to switch to hdmi output - so maybe use that in your movie example

              Comment


              • @Svartalf

                While testing VLC i got this error: "Please update alsa-lib to version 1.0.24 or higher to try to fix this issue." - basically you can update alsa-lib locally, that's what i do in my vlc script. The funny thing about this error is that alsa-lib 1.0.24 has not even a rc yet

                Comment


                • Originally posted by drag View Post
                  The solution is for Application-level type programmer is to ignore PA/Alsa/OSS altogether.
                  Sadly, that's not as easy as you're making it out to be.

                  You just use whatever audio library that works for your type of application.

                  You program in SDL or OpenAL or whatever. That way you benefit from the expertise and shared experience that the library developers have built up. All these audio libraries support PA nowadays.
                  Okay... Let's go through what edges are supported with the popular API edges, shall we?

                  SDL : OSS, ALSA, PA
                  OpenAL : OSS, ALSA, PA
                  FMOD : OSS, ALSA, ESD
                  FMOD Ex : OSS, ALSA, PA
                  IrrKlang : ALSA
                  Miles : OpenAL (?)

                  So, if your game uses FMOD classic (and there's quite a few that do...) you're out of luck. Ditto if you're using IrrKlang. Either we need to be better about educating the middleware crowd about PA, or we're going to have to find cleaner answers for the low-level access APIs.


                  Also you gain a lot of portability. SDL audio will work well enough across OS X, Windows, Linux, FreeBSD, Solaris, Haiku... etc etc.
                  Yeah, and it also has some...interesting...quirks about playback when you use SDL_mixer against PA and no real 3D sound support. OpenAL with some higher-level library support would probably be better as a choice if you're implementing something. I'd had high hopes for cAudio, but trying to use 2.X hasn't panned out as planned. OpenAL's nice as a mid-level API- but it is too clumsy for use as a sole framework by itself.

                  If you target OSS you only can run your application on FreeBSD or Solaris. If you target Alsa you can only run your application on Linux. If you target Pulseaudio you can only run your application on Freebsd/solaris/Linux (even though PA is portable to Windows and OS X both of those systems already have their own PA-style audio servers)

                  That sort of thing.
                  Actually, if you target OSS, you can get BSD, Solaris, AND Linux (either through OSSv4 being installed or the varying OSS support options- albeit that some configs won't work right that way...). If you target ALSA, you're right- it's only Linux. Does *BSD and OpenSolaris support PA? Does PA run atop OSS or ALSA drivers then? If not, you just negated the remark- as *BSD and OpenSolaris/Solaris use OSS from my recollections of things.

                  Comment


                  • Originally posted by Kano View Post
                    @Svartalf

                    While testing VLC i got this error: "Please update alsa-lib to version 1.0.24 or higher to try to fix this issue." - basically you can update alsa-lib locally, that's what i do in my vlc script. The funny thing about this error is that alsa-lib 1.0.24 has not even a rc yet
                    Nice... Thanks for the tip. I'll check into it.

                    Comment


                    • So it all seems to boil down to sound, dunnit?

                      Sound in Linux is a "problem", depending on how you want to look at the situation. The problem is not a simple one, it is a rather complex mess that has been crated over the years and the many migrations that have occured... What we currently have is the result of that which is a mixed environment and the fact that many of us still run old OSSv3 applications with ALSA, and even though it offers a fallback it cannot offer all its features to OSS applications, paramount to this is that dmix will NOT, and I repeat: dmix will NOT work with OSS streams being parsed to the main ALSA system through the alsa-oss wrapper, period! The end result for the very topic of this particular thread: Older games, unless migrated, will not work properly with ALSA without Pulse, period.

                      Add to this cunundrum the fact that pretty much all audio hardware in Linux (through ALSA or OSS) works at the hardware level with only ONE stream, and we have what we currently have in the Linux scene, a mess. The mixed environment is the main difficulty that has to be overcome... And many will still want to run the older applications (even closed applications) on their new systems and get frustrated because they don't work... HELL there are still some poeple running libc5 (yes, five) applications, and it's been over 11 years since the libc wreck, not to mention the gcc2.95 issues and the list goes on and on... It seems these kind of problems have been inherent to Linux' evolution.

                      The idea behind PulseAudio or a sound system is not alien to the "other" operating systems either. The Windows Sound System is exactly a sound server that mixes streams and stands between the applications and the drivers. The only difference, IIRC is that in the case of the DirectX drivers, DirectSound also functioned as a server or something to that end. In the MacOS side of things CoreAudio is the one responsible for the same thing, however in the case of MacOS the line seems to be a bit more blury between the sound system (server) and the actual drivers, much like is the case in the Linux camp with OSS and ALSA and aRts, ESD, Pulse, etc. However, I do know that CoreAudio actually consists of two parts, one being the sound server, and the other the collection of drivers.

                      The heterogenity of user experience in the case of Audio on Linux and particularly Audio on the Linux Desktop virtually boils down to two things: Different degrees of support for hardware (some cards supporting hardware mixing, others that are capable not being supported, and many not offering it) and mixed userland and application sound system support: Virtually all sound producing applications support OSS as a fallback, and there are still many applications that do not support ALSA. ALSA supports OSS through a wrapper (yes!, the fun never ends!), but this wrapper does not play well with other ALSA plugins (read, dmix). Hence a middle-ware has been developed, one which is actually part of the actual sound system (and to some degree ALSA and OSS provide) in the other OSes, and yet again had to be developed as a plug-to-a-hole in Linux, only better engineered this time, PulseAudio.

                      Now, I do not believe Pulse is a bad thing as such, but one of two things should happen:
                      • Either merge Pulse into ALSA or
                      • Simplify ALSA to the point that Pulse will do all the heavy lifting...

                      There would be one other option: Make an ALSA plugin as simple to interact with as Pulse (and make it blazing fast and efficient at soft-mixing for those cases needed**)

                      Individual hardware idiosyncracies only add to the cunundrum and can actually explain the varying degrees of support under ALSA.

                      **Such as single-stream hardware like the ubiquitous HDA , limited stream hardware (VIA82xx and others, which support from 2 to 4 HW streams) and extended stream support for robust hardware such as EMU10k1/2 chipsets (which support up to 32 streams, 24 usable by ALSA).

                      Comment


                      • Originally posted by mugginz View Post
                        I found Windows to be quite nice with bluetooth headsets. I will say though that some of the cheaper bluetooth dongles come with some appalling software but the Microsoft native stuff is pretty good.
                        This was with the Microsoft native drivers. I had to do an elaborate dance of pairing my headset with the computer everytime I wanted to use it. And god help me if it somehow decided to pair with my cell phone.

                        Originally posted by mugginz View Post
                        How easily did you configure ALSA to play with your bluetooth headset?
                        I never bothered. But the issues above applied to Mac OS X as well.

                        Originally posted by mugginz View Post
                        The sign of a mature system is the ability to deal with both mandatory as well as other non-core but nice features.

                        Person A - "But I can't get sound to work with my bluetooth headset...."
                        Person B - "Oh you're one of those strange people that want to do something that's not normal sound playback. Go read this FAQ and add that patch and edit these config files and then reboot. Now when you want to go back, edit this config and execute that shell command"

                        Isn't it time to get past just providing the simplest of sound support and also allow people to be able to depend on other more modern things as well. Do we need to remain the "Soviet Era" of multimedia for ever?
                        How many people have bluetooth headsets? Now, how many people play games?

                        As the subsets of users who will play games is much higher than those who will use Bluetooth headsets, they come first in terms of defaults. With the people with Bluetooth headsets having the option to install PulseAudio on their own.

                        Comment


                        • Originally posted by Thetargos View Post
                          Now, I do not believe Pulse is a bad thing as such, but one of two things should happen:
                          • Either merge Pulse into ALSA or
                          • Simplify ALSA to the point that Pulse will do all the heavy lifting...

                          There would be one other option: Make an ALSA plugin as simple to interact with as Pulse (and make it blazing fast and efficient at soft-mixing for those cases needed**)
                          I agree with this. However, I would to see an analysis of how much work either of your presented options will take.

                          Right now, I think etiher of your presented opinions weel take much more works then just improving OSSv4. I also question whether either path will have the ability to maintain ABI stabily with the current implementations of ALSA. Most applications are already compatible with OSSv4 via the OSSv3 fallbacks.

                          Comment


                          • Originally posted by darkphoenix22 View Post
                            How many people have bluetooth headsets? Now, how many people play games?

                            As the subsets of users who will play games is much higher than those who will use Bluetooth headsets, they come first in terms of defaults. With the people with Bluetooth headsets having the option to install PulseAudio on their own.
                            Rubbish. It's 2010. Linux needs to support both.

                            Comment


                            • Originally posted by darkphoenix22 View Post
                              I also question whether either path will have the ability to maintain ABI stabily with the current implementations of ALSA. Most applications are already compatible with OSSv4 via the OSSv3 fallbacks.
                              PA has OSS support also.

                              Comment


                              • Originally posted by Svartalf View Post
                                Sadly, that's not as easy as you're making it out to be.



                                Okay... Let's go through what edges are supported with the popular API edges, shall we?

                                SDL : OSS, ALSA, PA
                                OpenAL : OSS, ALSA, PA
                                FMOD : OSS, ALSA, ESD
                                FMOD Ex : OSS, ALSA, PA
                                IrrKlang : ALSA
                                Miles : OpenAL (?)

                                So, if your game uses FMOD classic (and there's quite a few that do...) you're out of luck. Ditto if you're using IrrKlang. Either we need to be better about educating the middleware crowd about PA, or we're going to have to find cleaner answers for the low-level access APIs.
                                Yeah. It's to bad we can't fix obsolete proprietary libraries. But fmod has always seemed to have been a problem for me. It's been a while since I've ran across any sort of need to ever install it.

                                But either way you'd still have to agree that from a game designer's point of view that having to write a entirely new audio structure on top of Alsa is undesirable when it's extremely likely that Linux is going to remain a tiny percentage of potential users/customers.

                                Choosing a library that is portable to Windows and OS X is going to be a big advantage.



                                Yeah, and it also has some...interesting...quirks about playback when you use SDL_mixer against PA and no real 3D sound support. OpenAL with some higher-level library support would probably be better as a choice if you're implementing something. I'd had high hopes for cAudio, but trying to use 2.X hasn't panned out as planned. OpenAL's nice as a mid-level API- but it is too clumsy for use as a sole framework by itself.
                                Well SDL has the advantage that your probably already depending on it for a lot of features for displaying 2D (and possibly 3d, although I expect most engines would target OpenGL) and for dealing with input controls (keyboard, joystick, mice). So using it for Audio is a nice move.

                                OpenAL sounds like it's something that you'd only want to use for bigger games were audio is part of the gameplay. In that case I expect that your moing into the realm of 'Game Engines' were the average game author is just purchasing or using a engine made by another team. After all people would much rather be spending hours/money making the actual game then programming in OpenGL or DirectX.

                                Plus you have Creative trying to push OpenAL support for Windows as a alternative to no-hardware-acceleration-allowing audio system used in Windows 7 and Vista. Audio hardware acceleration is completely dubious, at best, but at least you'll know the support is going to be there for OpenAL from Creative.

                                (but I suppose given Creative's track record this may be a minus)



                                Actually, if you target OSS, you can get BSD, Solaris, AND Linux (either through OSSv4 being installed or the varying OSS support options- albeit that some configs won't work right that way...).
                                No I don't think that targeting OSS would help out much for Linux at all.

                                OSS support in Linux sucks REALLY BAD, at best. It's a complete usability nightmware. CUSE + PA would probably give the highest level of support you'd ever hope to see except for the very tiny minority of users (like 1 in thousand) that are crazy enough to actually bother installing OSSv4 drivers in Linux.

                                Hell, for my purposes CUSE + PA would be superior then just using OSSv4 if I cared about OSS compatiblity since that would mean I would not have to abandon the sleep/hibernate capabilities of my laptop.

                                (and no, killing all my applications so I can turn OSS off before suspending is not acceptable)

                                Plus... as a game designer.. do you really care that much about FreeBSD or Solaris? I think that the people that hack on those systems only rarely use them on the desktop, preferring OS X or Windows.

                                I would expect for a people like Valve or other game makers that Windows, OS X, and Linux would be the priorities (in that order). OSS really does not get you any advantages if that is true.

                                Unless in some distant future OSSv5 takes over Linux, which is extremely unlikely. The Linux folks would essentially require OSS folks to reengineer their APIs to suit Linux driver requirements. Who do you think would budge first?

                                If you target ALSA, you're right- it's only Linux. Does *BSD and OpenSolaris support PA? Does PA run atop OSS or ALSA drivers then? If not, you just negated the remark- as *BSD and OpenSolaris/Solaris use OSS from my recollections of things.

                                Yeah. Pulse Audio supports OSS. It's designed to be portable.

                                http://www.freebsdsoftware.org/audio/pulseaudio.html

                                Although I doubt that you'll get all the features you get in Linux. (simply because they simply don't exist in other *nix systems.)


                                http://www.pulseaudio.org/wiki/About...eratingSystems

                                Linux, NetBSD, FreeBSD, Solaris, and Win32 are officially supported systems. I've seen people trying to get it working on OS X for some bizzare reason, too.

                                I still don't think it's terribly useful as a portability solution since Windows Vista/7 and OS X already have perfectly good audio services.

                                ---------------------------

                                BTW, OS X's Core Audio is generally regarded as a superior solution to what other OSes currently offer.

                                It uses a daemon, Coreaudiod. Capable of very good performance from what I hear.
                                http://www.manpagez.com/man/8/coreaudiod/

                                Comment

                                Working...
                                X