Linux is not ready for Steam

[drag]

This must be why I couldn't install UT99 some time ago. It claimed that the installer wasn't an executable.

There are lots of things that could cause that. For example: It's a shell script or other interpreted language and the person that wrote it hardcoded it to a interpreter that can be moved, instead of using the 'env' command to locate it for them.

I wouldn't say putting the startup script somewhere in your path is a bad idea. *.desktop files don't work in the terminal. A usable terminal is a major advantage of a Linux system.

You can still use a terminal. The user can just find the executable in /opt/$app-name/bin/ and if they would like they can add it to their path accordingly. A guy used to using a terminal for stuff should not have a problem figuring that out.

The thing that sucks about $PATH is that it can be anything. I would avoid trying to write to /bin/ or /usr/bin/ and things like /usr/games/bin is very distro-specific. Symbolic link to /usr/local/bin/ is probably the best place, but even then it's not 100%.

[darkphoenix22]

For games that need direct control over latency: http://www.pulseaudio.org/wiki/LatencyControl

So I get to control the buffer size...

Ya, this isn't a solution. Like Svartalf, as soon as you add a a layer of abstraction via a wrapper, you automatically latency. Especially when using programs and APIs that weren't intended to tolerate a wrapper. You are never going to be able to convince developers to recode their code to tolerate something that wasn't supposed to be there in the first place.

The status quo can not be fixed due to architectural problems.

The only real solution at this point is to put all or most of the functionality of PulseAudio directly into the ALSA API or simply replacing it with another API like OSSv4. I'm in favour of whatever will be economically cheaper.

[drag]

Luckily, NVIDIA and AMD provide OpenGL 1, 2, 3 and 4 drivers. Games will always support multiple renderers, and the OpenGL 2 renderer won't go away for quite some time. So, for the small percentage of people who don't run the proprietary drivers, the games will still work.

Yeah. No.

You have it backwards. The minority of people run proprietary drivers on Linux.

In, general, if you combined the amount of people using ATI and Nvidia into one big pool you will not come close to the number of people using integrated Intel graphics.

If all the game developers cared about was targeting Linux users on Phoronix running the latest and greatest of everything then they probably would not have to care about MESA-based drivers.

But if they actually want to have some sort of market and have the possibility of ever making money or garnering a lot of users... then only caring about proprietary drivers are a no-go.

[curaga]

PROBLEM: Need launcher on user's desktop
-----------------------------------------
...
PROBLEM: Need to provide QuickLaunch-style icon in the systray
----------------------------------------------------------------

Ewww. You're free to have your .config/.local/.$NAME dir, but never ever try to mess with my ~ beyond that. Don't try to put anything to my desktop, my autostart, and especially not to my tray.

These unwanted, unasked additions would just irritate people. It's practically malware.

[drag]

So I get to control the buffer size...

Ya, this isn't a solution. Like Svartalf, as soon as you add a a layer of abstraction via a wrapper, you automatically latency. Especially when using programs and APIs that weren't intended to tolerate a wrapper.

Stop and think about what your talking about.


-----------------------------

IF all your application library or application targets is OSS then _yes_ you have to deal with a wrapper. There is no real way around this.

OSS support in Linux sucks. It is unreliable, undependable, user unfriendly, etc etc.

It will NEVER not suck. I don't give a crap if you plan to offer OSSv4 in your hobby Linux version or not. It's not going to make any difference and the chances of OSS ever NOT being crap is about 0.

Even with CUSE + PA solution, which I mentioned before, were Linux distributions can implement 100% compatibility with OSS (yes even old Quake4-based games with it's DOS-era mmap sound support) nobody gives a crap enough to implement support in their distributions.

I wish they did, but as far as I can tell they don't.

Actually trying to use OSS drivers in Linux does nothing but makes the whole system worse.

---------------------------------

As far as PA goes...

You NEED to implement software mixing in the audio stack.

This is NOT optional. If you want a modern OS with any decent hardware support and performance then you are ABSOLUTELY going to have to implement a software mixer.

You do NOT have a choice in the matter. It's a bold faced requirement to have a minimally functional audio stack.

And it's going to add latency.

It does not matter if you do it in the kernel or in dmix or if you do it in PA. The effect is the same. There is no magic latency-reduction that you get by implementing mixing service as a kernel module or as a userspace daemon.

[Remco]

There are lots of things that could cause that. For example: It's a shell script or other interpreted language and the person that wrote it hardcoded it to a interpreter that can be moved, instead of using the 'env' command to locate it for them.




You can still use a terminal. The user can just find the executable in /opt/$app-name/bin/ and if they would like they can add it to their path accordingly. A guy used to using a terminal for stuff should not have a problem figuring that out.

That's a royal pain in the ass, and that results in an unusable terminal such as in Windows. Windows also has a PATH variable, so in theory you could fix it there, too.

The thing that sucks about $PATH is that it can be anything. I would avoid trying to write to /bin/ or /usr/bin/ and things like /usr/games/bin is very distro-specific. Symbolic link to /usr/local/bin/ is probably the best place, but even then it's not 100%.

I'd go for /usr/local/bin/, too. I'd use /opt/bin/, but no distro includes that in its PATH variable.

[Remco]

Yeah. No.

You have it backwards. The minority of people run proprietary drivers on Linux.

In, general, if you combined the amount of people using ATI and Nvidia into one big pool you will not come close to the number of people using integrated Intel graphics.

That's true, but Intel drivers offer OpenGL 2 through Mesa. And their hardware doesn't support anything more. So, yeah, game companies can't let go of the OpenGL 2 renderer. They can't let go of DirectX 9 on Windows either.

[darkphoenix22]

As far as PA goes...

You NEED to implement software mixing in the audio stack.

This is NOT optional. If you want a modern OS with any decent hardware support and performance then you are ABSOLUTELY going to have to implement a software mixer.

You do NOT have a choice in the matter. It's a bold faced requirement to have a minimally functional audio stack.

And it's going to add latency.

It does not matter if you do it in the kernel or in dmix or if you do it in PA. The effect is the same. There is no magic latency-reduction that you get by implementing mixing service as a kernel module or as a userspace daemon.

I will implement PulseAudio as soon as it has been demonstrated to work with existing code. As is, it breaks a few programs that are included with my distribution.

The solution provided by the PulseAudio developers, the suggestion that all existing code and drivers should be rewritten to tolerate the limitations and latency scheme of PulseAudio is simply unacceptable. This is, bottom-line, an unobtainable goal.

The fact that all code can't be rewritten to work with PulseAudio is further demonstrated by the fact things are still broken when using PulseAudio. These very applications worked completely under bare ALSA in my testing and OSSv4 under my friend's testing.

Games and PulseAudio mix like water and this is not because of bad or improper code. This is because of broken architecture and design.

[darkphoenix22]

Edit: Games and PulseAudio mix like water and oil and this is not because of bad or improper code. This is because of broken architecture and design.

Perhaps, with an another, simpler audio API, a wrapper would work. But I do not believe this possible with PulseAudio because of design. Not all applications and games can be satisfied with only the Pulse-safe subset of ALSA. PulseAudio provides no solution to this problem. Libsyndey has not either.

[Tomservo]

It depends on how the application implements sound. If it uses sound for timing, it's toast with PulseAudio due to the higher latency introduced by the wrapper/buffer. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.

I don't see how a wrapper increases latency, since it's simply said just abstracting APIs. No buffering of any audio. Any buffers are residing in the game's own mixer, which would be present in Windows versions, too.

And from what I've noticed, the userland mixer introduced in Windows Vista didn't hurt latency noticably either, compared to XP. Unless Pulseaudio is completely retarded, it'll work.