Linux is not ready for Steam

[darkphoenix22]

I think Valve should wait a year before porting Steam. The multimedia and audio frameworks and APIs on Linux are currently a mess. The APIs and frameworks need to be stablized before any sort of large scale professional game development can begin on Linux.

http://braid-game.com/news/?p=364

If Value ports Steam to Linux in its current state, I'm afraid it will become unprofitable and they'll quickly abandon it. If that happened, there would be virtually no professional Linux games for years.

Linux needs to be ready before we fall under the spotlight.

[darkphoenix22]

Although the article above is a bit old, it's still quite true. I tested around 20 games and emulators on Ubuntu. Although, some of them worked (they sometimes needed a bit of configuration), most required you to remove PulseAudio. Many games using the Allegro framework with SDL also required me to tell SDL to use OSS.

[crazycheese]

The multimedia

Gstreamer

audio

PulseAudio or OSS

on Linux are currently a mess.

Proof?
Also, there is SDL for any-platform you want any-library you want pain-free autodetection.

The APIs and frameworks need to be stablized before any sort of large scale professional game development can begin on Linux.

I dont notice any bugs in Pulse since 2009.

http://braid-game.com/news/?p=364

Their first ubuntu install?

If Value ports Steam to Linux in its current state, I'm afraid it will become unprofitable and they'll quickly abandon it. If that happened, there would be virtually no professional Linux games for years.

Utter garbage. I hear about some project to gather 1 Billion $ for several linux games recently, where everyone could deside the bundle price <themself>.

Linux needs to be ready

Its not Vista. Define the word "ready". For software, it is ready many years ago.

before we fall under the spotlight.

Them (braid-whatever dot whatever) better say in dark than fall under my spotlight with utter crap arguments.

Install Ubuntu(yes its so hard),
Install Code::Blocks,
Create new template SDL project.
Very very hard and unready. +Facepalm+

[crazycheese]

Although the article above is a bit old, it's still quite true. I tested around 20 games and emulators on Ubuntu. Although, some of them worked (they sometimes needed a bit of configuration), most required you to remove PulseAudio.

For what reason?

Many games using the Allegro framework with SDL also required me to tell SDL to use OSS.

Allegro is pretty dead.
SDL can be compiled to ANY library. It can also be compiled with ALL libraries support, you have to set single envvar to tell it what it should use.
If you are using OSS and have single card, you pretty much dont need PulseAudio.
But OSS, like Microsoft, is known for backstabbing.
Besides, Pulse takes 20Mb RAM at peak for all options it gives.

[darkphoenix22]

Game developers are not going to want their users to have to reconfigure their entire sound system to run their games.

Most of the emulator used bare SDL for their audio. Still had to remove PulseAudio, though most did work with ALSA. All worked with OSS.

Allegro is alive and well they've made quite a few releases in the past 6 months and are about finished their rewrite.

[darkphoenix22]

Much of the problems stem from how PulseAudio works.

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

PulseAudio sacrifices latency for power consumption. High latency, low power consumption. The power saving is also why your computer makes those clicking noises when running Ubuntu. That's PulseAudio shutting off your audio chip.

I'm not sure how beneficial low power consumption from your sound chip is to battery life anyways. It's your CPU, GPU, WiFi, Bluetooth, and LCD panel that take up all the power. Not really sound.

Note: My tests were done with the latest ALSA drivers IIRC.

-----

PulseAudio also only supports around 70% of the ALSA routines. libsyndey was supposed to come along and allow it to support the other 30%. libsydney stalled and has been virtually abandoned. ALSA is simply too complicated to be effectively used with a wrapper.

http://lwn.net/Articles/299211/

Note: The above link is also a bit old, but many of the issues it touches on still apply today.

[prophet5]

I don't disagree on any particular point, just that I have not experienced any problems with pulseaudio itself. There have been a few games that required setting the sound server manually. Doom3 and Quake4; changing the audio setting from "Best" to "OSS" gives sound. Enemy Territory always had sound issues before pulseaudio came along, hence the SDL version. I've had no problems with games that use OpenAL.

Of course I'm not using a laptop, and to honest, unless the lappy you use is a desktop replacement with dedicated everything, it's (still) not worth playing games on one.

[darkphoenix22]

I don't disagree on any particular point, just that I have not experienced any problems with pulseaudio itself. There have been a few games that required setting the sound server manually. Doom3 and Quake4; changing the audio setting from "Best" to "OSS" gives sound. Enemy Territory always had sound issues before pulseaudio came along, hence the SDL version. I've had no problems with games that use OpenAL.

Of course I'm not using a laptop, and to honest, unless the lappy you use is a desktop replacement with dedicated everything, it's (still) not worth playing games on one.

I agree that many games can work with a bit of elbow greese and configuration. Unfortunately, many users are not capable of performing such configuration. Game developement companies will want their games to work out of the box.

[darkphoenix22]

Of course I'm not using a laptop, and to honest, unless the lappy you use is a desktop replacement with dedicated everything, it's (still) not worth playing games on one.

I think that's the problem right there. It's mostly laptop chips (and intergrated desktop chips) that are having these problems as they use the CPU for the acceleration.

[crazycheese]

Much of the problems stem from how PulseAudio works.

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

PulseAudio sacrifices latency for power consumption. High latency, low power consumption. The power saving is also why your computer makes those clicking noises when running Ubuntu. That's PulseAudio shutting off your audio chip.

I'm not sure how beneficial low power consumption from your sound chip is to battery life anyways. It's your CPU, GPU, WiFi, Bluetooth, and LCD panel that take up all the power. Not really sound.

Note: My tests were done with the latest ALSA drivers IIRC.

-----

PulseAudio also only supports around 70% of the ALSA routines. libsyndey was supposed to come along and allow it to support the other 30%. libsydney stalled and has been virtually abandoned. ALSA is simply too complicated to be effectively used with a wrapper.

http://lwn.net/Articles/299211/

Note: The above link is also a bit old, but many of the issues it touches on still apply today.

What? Sorry, but low-latency server is JACK. Pulse is much more latent and high-latency & high perfomance vs low-latency vs low-perfomance are not related to Pulse. Its either faster reacting(but doing less work) and consuming more or slower reacting(and doing more work) and consuming less. Same reason why RT linux kernel is slower in server(ie constant load) environiment.

Pulse clicking is ubuntu issue.
If application uses a library to output the sound, gstreamer, sdl, openal, doesntmatter what. And this library is wrongly configured to output sound to ALSA. But Pulse is installed and alsa.conf points to pulse. This thing happens:
Some game>>libsdl>>alsa(reroutes to pulse)>>pulse>>alsa you hear clicky-noise

Where if that lib attaches itself to pulse correctly:
Some game>>libsdl>>pulse>>alsa

I have no clicks or anything with pulse. I also do not really care for ubuntu not doing their homework. Gentoo and PA perfect setup describes pretty much clearly how to link PA with libs, apps and soundsystems.

Didnt check on 70% issue, so I believe you. But again, not single desktop app working wrong with PA+Alsa up to date.

I don't disagree on any particular point, just that I have not experienced any problems with pulseaudio itself. There have been a few games that required setting the sound server manually. Doom3 and Quake4; changing the audio setting from "Best" to "OSS" gives sound. Enemy Territory always had sound issues before pulseaudio came along, hence the SDL version. I've had no problems with games that use OpenAL.

Of course I'm not using a laptop, and to honest, unless the lappy you use is a desktop replacement with dedicated everything, it's (still) not worth playing games on one.

Athlon 3200 on NF-7S v2.0, VIA AC97 chip.
Intel E5300 on P43ME, VIA VT1708S
Athlon II x2 240 on ASUS M3N78-EM, Realtek ALC1200
Asus A6Rp notebook with some ATI chipset
Athlon II x4 630 on Gigabyte GA-MA785GMT-UD2H 1.1, Realtek ALC889A

Not a single problem.
Of course this isnt major industrial-level testing and I cannot speak for PA as whole. However applications SHOULD use either libSDL or libopenAL or if they require more features gstreamer, xine or even managin whole sound pipeline themself by using alsa/oss and codecs/libs directly. This is however has issues. Because you required close-to-system calls, you should support it. Higher level libs do not offer the features which arent generic or cannot be emulated. But if you program this way, your app has pretty much in similar with DOS era. Writing your own drivers, mixer etc. You asked for it.

Of course there may be driver problems within ALSA. There may be problems within SDL and Pulse(especially in case I described above; just install SDL-pulse version only, not of all-in-one). But system is there, frameworks are there and they work!

Now dont tell me DirectX(Directsound, -music or however it is called now) is consequent and API and sound model was never changed
It did, devs pushed new versions, everything worked to some degree, then got broken again and again etc. I dont see how linux is "not ready" here. In fact linux is more ready than windows; you just put sound chip manufacturer publishing specs for new chips and game publishers updating their software(regardless foss or proprietary) and it works.