Originally posted by pingufunkybeat
View Post
Announcement
Collapse
No announcement yet.
Linux is not ready for Steam
Collapse
X
-
-
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 not into feeling and thinking about things I don't have enough information about. It seems like you don't know these things either.
Comment
-
Originally posted by pingufunkybeat View PostI'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.
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.
Comment
-
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 PostAs 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.
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 PostSo 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
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?
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
Comment