Linux is not ready for Steam

[Tomservo]

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.

Maybe it's just my practical idealism, but I figure that anyone that may consider playing the Linux ports of the Source games would probably own or procure decent hardware.

And even if not, since the Mac environment presents same the integrated Intel vs. ATi/NVidia rift, it's safe to assume that the Source ports will feature different GL render paths.

[darkphoenix22]

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.

And this is the problem. PulseAudio doesn't allow access to all the APIs needed in ALSA in gaming for timing. Games and programs that are not programed to be tolerate of a bare buffer instead of direct hardware access will fail when using PulseAudio. As this is a common programming technique for games on every operating system, game developers are not going to change their development methodology to suit the needs of PulseAudio. They give up and will look elsewhere.

For better or for worse, PulseAudio is a demonstrated barrier for programming games on Linux. Changing how every games and game library is programmed is not the answer as this is a solution can never be completed.

An incomplete wrapper like PulseAudio will never work with games that require direct sound hardware access (even if it is through a library). And sadly, this is the majority of games.

[darkphoenix22]

Simply put, ALSA is too complicated and expansive of an API to allow for a wrapper that will work for all situations. ALSA was never designed to be used with a wrapper and will never work completely with a wrapper. Period.

[kazetsukai]

Simply put, ALSA is too complicated and expansive of an API to allow for a wrapper that will work for all situations. ALSA was never designed to be used with a wrapper and will never work completely with a wrapper. Period.

Ugh, I had to join and say something. After thumbing through this entire thread, I cannot see a single supporting factor against ALSA in any of your claims. I've had -perfect- working dmix configurations with ALSA since a year or two after it was introduced (I cannot remember the specific timeframe), and now sound configuration for me involves plopping a simple asound.conf into /etc/.

pcm.snd_card {
     type hw
     card 1
}

pcm.dmix {
     type dmix
        ipc_key 1024
        ipc_key_add_uid false
        ipc_perm 0660
        slave {
                pcm snd_card # see below
                rate 48000
                channels 2
        }
     }


pcm.duplex {
    type asym
    playback.pcm "dmix"  # just pass to dmix.
#    capture.pcm "usbcam" # or whatever capture device
}

pcm.!default {
     type plug
     slave.pcm "duplex"
}

pcm.dsp "duplex"
pcm.dsp1 "duplex"

Mixing problem solved. PulseAudio, OpenAL, WHATEVER will now mix audio using DMIX from that point onward (as long as they're configured to use ALSA), which is more or less what the majority of users require. In many cases this type of default configuration is provided by the distribution maintainer.

Your claims for Per-App volume control being "beyond" ALSA's capability are also pretty silly. All ALSA needs to do is automagically add a mixer control for every application access. The difficulty of adding this functionality is really in the implementation, not for you or I or -anyone- outside of the ALSA project to comment on.

Before even that, I don't see the critical need for such a feature. I don't have a million volume knobs on my amp for each input, I have one: VOLUME. That's all I need, and all I really care about when it comes to it. Most applications that need such control have their own volume configuration anyway- Don't believe me? Look at almost any PC game or media player out there. They all have their own volume control. This kind of useless feature is what creates bloat and turns our Linux sound experience into some obscure sound "server".

Your advocacy for OSSv4 is also really unjustified- it is incomplete, has none of the more advanced features ALSA has, and most importantly isn't proven on the desktop. It cannot possibly be considered as a viable replacement until it provides 100% of the basic functionality that all users need out-of-box, and doesn't get in the way of other (currently working) solutions. It currently fails both conditions.

Better idea - Fix ALSA's real problems. How about implementing the holy grail of sound - Mixed DDL? Fix the (in most cases minor) performance issues and get DMIX + the A52 encoder playing nice together, that'll make alot of people happy. Currently some implementations like that cannot be pipelined as expected, which is (as far as I know) ALSA's only real limitations, and can most certainly be fixed through the normal bug chasing or reimplementation of those features.

[darkphoenix22]

Your advocacy for OSSv4 is also really unjustified- it is incomplete, has none of the more advanced features ALSA has, and most importantly isn't proven on the desktop. It cannot possibly be considered as a viable replacement until it provides 100% of the basic functionality that all users need out-of-box, and doesn't get in the way of other (currently working) solutions. It currently fails both conditions.

Better idea - Fix ALSA's real problems. How about implementing the holy grail of sound - Mixed DDL? Fix the (in most cases minor) performance issues and get DMIX + the A52 encoder playing nice together, that'll make alot of people happy. Currently some implementations like that cannot be pipelined as expected, which is (as far as I know) ALSA's only real limitations, and can most certainly be fixed through the normal bug chasing or reimplementation of those features.

Then let's fix ALSA.

If the choice is between fixing ALSA and switching to OSSv4, I'm in favour of what will take less work and cost less money.

[darkphoenix22]

In the end, our decision should not be based not politics or perceived technological superiority. It should be solely based on which path is cheaper and easier to take to reach our goal. This goal is to have a default sound API situable for game development on Linux, without hacks or compromises like PulseAudio.

The path we take should be left to pure economics.

[darkphoenix22]

Edit:

In the end, our decision should not be based on politics or perceived technological superiority. It should be solely based on which path is cheaper and easier to take to reach our goal.

This goal is to have a default sound API suitable for game development on Linux, without hacks or compromises like PulseAudio, while being able to be extended to meet the needs of future developers and users.

The path we take should be left to pure economics.

[kazetsukai]

Edit:

In the end, our decision should not be based on politics or perceived technological superiority. It should be solely based on which path is cheaper and easier to take to reach our goal.

This goal is to have a default sound API suitable for game development on Linux, without hacks or compromises like PulseAudio, while being able to be extended to meet the needs of future developers and users.

The path we take should be left to pure economics.

The cheapest solution is rarely, at best, the best long-term solution for any problem.

[darkphoenix22]

The cheapest solution right now is to remove PulseAudio and let ALSA be.

What I mean by pure economics is what will cost Linux less in the long run in terms of work? Extending ALSA or improving and testing OSSv4, a much simpler API?

Whatever is economically cheaper in terms of work and cost in the long run is the path I would like to take.

[pingufunkybeat]

Can you point me to a source which compares the OSS and ALSA APIs from an application developer POV?

You keep saying that ALSA is too complex and OSS is very easy, and I've kept asking you why you say this, and you haven't answered.

Are you a multimedia programmer? Have you written an ALSA and/or OSS backend? How do you know this?