Linux is not ready for Steam

[pingufunkybeat]

QTmobility != QT

From the link:

The new Qt MultiMedia APIs introduced in this blog fall in that category, as they are of course *also* designed with the needs of desktop application developers in mind.

Qt Multimedia is a substitute for Phonon, which was the old way for Qt to play sounds.

[pingufunkybeat]

Yea sure KDE does not need PA just as long as you don't actually install any applications that are not as part of the default install. Then you may or may not need to install it.

Is there a single application out there which will refuse to work without PA, and have no ALSA or OSS backend?

[chaperon]

Steam is not coming to Linux, and if it is, it won't care about the sound system.

I agree. Steam won't care about sound system and game engines will care about high level gaming sound systems (OpenAL, FMod, SDL) so these must work flawlessly out-of-the-box. OpenAL is still so-so depending on your setup/hardware and SDL is just a pain with PA (CPU usage too high, when sound doesn't skip).

Please stop the troll about ALSA/OSS/PA, this has nothing to do in a gaming thread, except if it improves high level libraries behaviour. I repeat : the goal is mid-low latency (20ms - 1024 samples buffers @ 48k), with lowest CPU possible and a stable sound output in out-of-the-box state (casual gamers are barely capable of installing a game on Windows).

Fancy features are not needed for games, so most of PA features are unuseful. JACK is overkill - its aim is professional audio production, with buffers as small as 16 samples, and it does not meet the "low CPU" requirement.

What I would like to see to keep constructive is a troll about ALSA/OSS/PA as a backend for OpenAL/SDL, PA's waste of CPU resources (if any) and default configuration in distributions useable by my grandmother (gentoo is NOT in that category).

All this nerdy bullshit about USE flags, PA enabling/disabling, selecting another mixer instead of the default out-of-the-box one, touching ANY text configuration file definitely explains WHY Linux is still not ready for gaming. Gamers want to play, not to make games work, that's the job of distribs. Also, that's NOT Valve's job : they won't attempt anything to make it work and provide support, they just want to make money by putting working games on a list and charge for it. This is also NOT the job of game studios : these people just expect high level libraries to work and will tag any approximative platform as unsuitable without thinking furthermore (except for Windows, which has a somewhat bigger marketshare).

[pingufunkybeat]

I don't get the part about USE flags, PA enabling/disabling, selecting mixers, configuration files, etc.

How many commercial Linux games have you purchased? I've bought about a dozen (though I'm not much of a gamer at all, just like the odd distraction) and they all worked out of the box, with zero problems.

The only exception were the early Doom3 demos, which demanded OSS + mmap at a very specific frequency (which won't work on PulseAudio either). Later, they added an ALSA backend, and that worked as well.

Of course, the open source games all work without issues too.

[deanjo]

Is there a single application out there which will refuse to work without PA, and have no ALSA or OSS backend?

Pulseaudio apps such as their mixer, etc. That's about it.

[chaperon]

Of course, the open source games all work without issues too.

Of the few games I play under Linux, Neverball (OpenAL), vDrift and PrBoom had severe drops. And SDLMAME is just unusable (plain SDL sound). All of this is on an unmodified Ubuntu 9.04 and 9.10. All these problems just went away with 10.04, but I noticed very high CPU usage and increased latency when using PA (compared to plain ALSA).

I am not interested into making this work better, I just expect this to "just work", and it does not. My distro is using PA. When I disable it, I lose software mixing and it renders my SIP phone useless but my problems in games just go away.

OK, I will just give my opinion for the gaming side : PA is great for "normal" applications (media players, sound events) but I need pasuspender to play most games, which is no good.

[IsawSparks]

Of the few games I play under Linux, Neverball (OpenAL), vDrift and PrBoom had severe drops. And SDLMAME is just unusable (plain SDL sound). All of this is on an unmodified Ubuntu 9.04 and 9.10. All these problems just went away with 10.04, but I noticed very high CPU usage and increased latency when using PA (compared to plain ALSA).

I am not interested into making this work better, I just expect this to "just work", and it does not. My distro is using PA. When I disable it, I lose software mixing and it renders my SIP phone useless but my problems in games just go away.

OK, I will just give my opinion for the gaming side : PA is great for "normal" applications (media players, sound events) but I need pasuspender to play most games, which is no good.

Sorry, but those are not examples of commercial grade software. They are volunteer projects each having different needs. PA IS fine. It works great and commercial games and applications which are compiled with Pulse support built are pretty much guaranteed to work lag free. PA is a good idea and good implementation. Yes, it definitely had issues in Ubuntu previously but that's been resolved and it's in my opinion, very much the future of Linux audio.

[pingufunkybeat]

How does Doom3 work with PA?

Is that commercial grade software enough? Or do only GNOME applets count?

OpenArena is often reported to have all sorts of troubles with PulseAudio.

[pingufunkybeat]

BTW, I was saying that all the commercial games I've purchased worked out of the box on ALSA.

They probably don't work on PulseAudio, because they require mmap like Doom3 and Quake4 or for similar reasons.

[chaperon]

Sorry, but those are not examples of commercial grade software. They are volunteer projects each having different needs. PA IS fine. It works great and commercial games and applications which are compiled with Pulse support built are pretty much guaranteed to work lag free.

These projects mostly use OpenAL and Neverball is based on Quake engine, which is commercial grade. Here only the high-level library counts. Still, what you say is true, but I would try to rephrase as : "The current OpenAL software implementation is not ready for PA".

Programming OpenAL as a game programmer means that you do not have control over latency, mixing techniques, driver bug workarounds, ... Even a basic test program will fail the same way as a commercial application because the problem lies between OpenAL and its sound output backend. OpenAL as a game programmer means that you only call functions to trigger sounds, so you cannot do things wrong.

If you say PA is good, then OpenAL is the problem. Unfortunately, FMod people may not have enough support because of the proprietary license, and FMod is used in many commercial games (it offers a good API and a nice GUI editor for sound effects).

In a way, we just have to make OpenAL and FMod work right in a fresh default environment, the underlying system is totally irrelevant as long as it meets requirements (20ms latency, minimal CPU).

After all, we are on Phoronix : benchmarks about CPU performance of various backends for OpenAL/SDL sound for various audio hardware would be definitely cool. Is there a way to make that ? Where do I start ? VDPAU/VA-API benchmark results are very interesting, the same for sound would be definitely a plus.