Page 11 of 50 FirstFirst ... 91011121321 ... LastLast
Results 101 to 110 of 500

Thread: Linux is not ready for Steam

  1. #101
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Quote Originally Posted by pingufunkybeat View Post
    Why?

    Says who?

    PulseAudio was created to replace ESD.
    If it was so easy to put per-application volume controls directly into ALSA, don't you think they would have done so already? Developers tend to go for the simplest solution, as they are lazy. They made PulseAudio because it was less work to add per-application volume controls and networkable audio via a wrapper than it was to add it directly to ALSA.

  2. #102
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    They also made it to replace ESD, but the reasons above are paramount.

  3. #103
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Notice how PulseAudio is advertised to new users in this announcement:

    http://fedoraproject.org/wiki/Releas...ary#PulseAudio

    PulseAudio was the path of less work compared to extending ALSA. I feel OSSv4 is the path of less work compared to extending ALSA to replace PulseAudio's functions.

  4. #104
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    If it was so easy to put per-application volume controls directly into ALSA, don't you think they would have done so already?
    I'm just asking for some facts and sources, that's all.

    I'm not into feeling and thinking about things I don't have enough information about. It seems like you don't know these things either.

  5. #105
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Quote Originally Posted by pingufunkybeat View Post
    I'm just asking for some facts and sources, that's all.

    I'm not into feeling and thinking about things I don't have enough information about. It seems like you don't know these things either.
    Well considering all the work they have done to optimise programs and drivers to work well with PulseAudio, I'm sure there's a reason. If their goals could have been satistfied by ALSA alone, there would be no need for coding.

    Source: https://lists.ubuntu.com/archives/ub...ay/011343.html

    People don't rewrite code for nothing. They do it because they feel they have to. And they do because they feel that it's the path of least resistance.

    BTW It's sad that even after all that work, there's still latency and compability issues with PulseAudio. Seems really like PulseAudio can't be fixed.

  6. #106
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    944

    Default

    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

  7. #107
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    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.

  8. #108
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote 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?

  9. #109
    Join Date
    Jun 2010
    Posts
    10

    Default

    Quote 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.

  10. #110
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote 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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •