Linux is not ready for Steam

[darkphoenix22]

And PulseAudio is far from transparent, as it doesn't even allow access to the entire ALSA API. This breaks quite a few games and programs and causes hell for programmers.

Having a plain buffer isn't always enough. Some things depend on hardware interupts.

These alternate solutions don't look as nice on paper as a single, clean sound server, but different applications have different needs. Not every program is a media player or a web broswer.

PulseAudio is an ideal that just doesn't stand up to reality.

[jasa68]

"Linux is not ready for Steam", first of ... what is the linux actually ready for in first place, it has the constantly developing things of from the things of kernel to software without really any stops around.

When we would talk around thing like Steam, we would talk a common thing in way of like Gnome desktop, it shows desktop that we can use things like browsers for internet, game on etc.

Steam would run on top of that and on around constant rush towards from those of developers from each side on.

Yes the Steam could run on minor issues on between gtk/qt sides and on around trying to please most of the persons while some minor thing would gone un-noticed, still being we are not really thinking on the "final" build things on like on the Windows side where one thing is set and on around fixes send to the current thing as if found but rather more features added to make the build more than it was previously that could eventually come as issue from the softwares that supported the older behaviour.

What is the final build for Linux/Gnu softwares eventually at end, user space of desktop and standart APIs of what folks could use to enrich the look and feeling of while on around some folks argue at around things like can or cannot Steam run on Linux we could read more of in articles around the internet can oss/alsa and wrappers pulse work on really.

(If you can run a web browser and random software that would work on it's behaviour do not whine too much, at some point hopefully they would come in agreement of software freeze points on from where no new features would be added but rather random bug fixes only for year or few like on some other software companies behaviour, what would eventually mean bit more stability towards the end users instead of throwing random new things on like currently.)

[darkphoenix22]

I just want a solid, flexible fiundation for Linux games to be built on.

[darkphoenix22]

Edit: I just want a solid, flexible foundation for Linux games to be built on. That follows the Unix philosophy.

[Dragonlord]

Edit: I just want a solid, flexible foundation for Linux games to be built on. That follows the Unix philosophy.

Don't worry, it's in the works.

[darkphoenix22]

For 2 years, ending up pretty much where it started.

[kazetsukai]

OpenAL and OpenGL. Programmers are such whiners these days though.

"You mean -I- have to do memory management? HAH!"

[Svartalf]

I would imagine he'll end up reading this thread and will respond when he does.

Oh, I can manage that... It's not so much MY abilities that are the problem as it's what other people do. Unlike with the Doom3 code, I don't always have the luxury of re-working the stuff to suit the framework like iD does- I'm stuck with what I'm handed more often than not. And it's not that the other people are incapable- they may have other needs within their game that doesn't allow for the same solution they did at iD.

And, more to the point, I think you'll find several other skilled people commenting on the problem (including some pretty skilled people at indie studios...) I've been pointing out earlier in the threads: You can't expect to wrap a broken framework with something to fix it- the best you will do is sweep the problem under the carpet.

Even if you assume PulseAudio IS the answer to things- with OSS and ALSA being effectively broken in varying and different ways, it's not going to be the right answer until you FIX that stuff underneath as there will always be some stupid lingering problem with it.

[Remco]

And, more to the point, I think you'll find several other skilled people commenting on the problem (including some pretty skilled people at indie studios...) I've been pointing out earlier in the threads: You can't expect to wrap a broken framework with something to fix it- the best you will do is sweep the problem under the carpet.

ALSA isn't really broken. It does what it is supposed to do. PA builds on that and exposes weaknesses in some of ALSA's API. I imagine that, for example, ALSA's unsafe API would become unusable when PA's features would be added to ALSA.

Even if you assume PulseAudio IS the answer to things- with OSS and ALSA being effectively broken in varying and different ways, it's not going to be the right answer until you FIX that stuff underneath as there will always be some stupid lingering problem with it.

If we sidetrack this flame-infested thread for a bit: have you considered contacting Lennart about PulseAudio's limitations for your use cases? Maybe some tricks can be pulled in PA to make classic Fmod and Allegro work.

[yogi_berra]

The old song. Instead of solving problems with better design moan about them and push the blame on others.

Are you suggesting that users should write their own documentation and their own audio library?