Linux is not ready for Steam

[darkphoenix22]

what 'functionality'?

besides, the latency argument is bogus. jack is 'another layer' and it does not have any latency problems.

But it was made by people who know what they are doing. And not some gnome infected.

PulseAudio doesn't provide access to the entire ALSA API. So applications that need access to the non-Pulse-safe subset of the ALSA API are borken when using PulseAudio.

[darkphoenix22]

More details, along with discussion from the original developer of PulseAudio: http://lwn.net/Articles/299211/

Note: This article is a bit old, but PulseAudio still works the same.

[blacknova]

Reprogramming everything to use only the Pulse-safe subset of ALSA is not an option as some applications *will* need the extra functionality provided by the direct ALSA API.

Forcing all software to use some high level api is the only way to ensure we wouldn't have such a thread in the future
I'm not saying this should by PulseAudio, no. But for consistent user's desktop experience it would be necessary.
Low level API like OSS or ALSA is not good for remote desktop users as in most cases they wouldn't get any sound at all.
For local users situation is different.
But anyway, most of software including games are not that latency dependent.
And that extra functionality that couldn't be provided by sound server you mean?

[blacknova]

As for low-level API, I would prefer OSS as it much less pain in ass and wouldn't need to use additional library just to play simple sound

[darkphoenix22]

The problem is this high-level API wasn't designed with games with mind. Nor does it allow for it to be bypassed so existing applications that use these non-Pulse-safe APIs still function. A high level buffer just isn't going to be enough for many cases.

Tweaking a buffer is not a solution. In many cases, it doesn't even solve the problem.

From someone who has experience developing games and progamming with these APIs:

Heh... This I can concur with. This has been my experience with PA- though I've tapdanced around it with the games I've ported over. PA's got "okay" latencies- but unless it's got lower ones going through it's direct API, it's not quite there for use in the context of titles. It causes all sorts of odd issues. No. many of the titles don't use the sound playback as a main timing loop- but the sounds are typically coded such that they're in lock-step with the typically 50-100msec timing atom that is present in many titles. The other game effects are timed against the sound playback to increase immersion (it does no good to pull the trigger on a gun, only to hear the gunshot sound start 110msec after you did it, as it'll start feeling like a bad Kung Fu movie dub over.

Disclaimer: I do not program games or audio applications. I have only tested and found applications that do not work with PulseAudio. I was wrong about the mechasmisms behind they don't work in some cases (ie. direct hardware access). This does not change the fact that some appllication I include by default with my distribution do not work with PulseAudio. In some cases the audio skips (mostly SDL games). In other cases, the audio does not work at all (95% of the Allegaro games I've tried). All the issues were resolved by removing PulseAudio.

From the OpenSonic devs: http://www.allegro.cc/forums/thread/600325

These cases are widspread and not isolated. Pretending they don't exist will not fix the problem. Expecting every piece of code ever created to be recoded to be tolerate of PulseAudio's buffering scheme will not fix the problem.

[energyman]

The latency argument applies to PulseAudio as it is a pure wrapper for ALSA. Jack directly interfaces with the kernel to provide the low latency. Ubuntu Studio even installs a real-time kernel to help mitigate the latency for audio work.

http://tuxradar.com/content/how-it-w...udio-explained

WRONG. You don't even know what you are talking about. Or read your own link. But here is a pretty picture for you:

http://jackaudio.org/files/JACK-Diagram-screensize.png

[blacknova]

Hm... last time I've checked on Linux my hdaudio interrupt handler have been called something around 10 times per second.
If dma buffer is updated at the same rate wouldn't that give us 100ms latency?

[darkphoenix22]

So Jack directly uses hardware interupts for the timing. PulseAudio uses a basic buffer.

My point exactly.

[darkphoenix22]

Hm... last time I've checked on Linux my hdaudio interrupt handler have been called something around 10 times per second.
If dma buffer is updated at the same rate wouldn't that give us 100ms latency?

It should at least be used a guideline.

[pingufunkybeat]

The "unified API everybody uses" is a pipe dream. It will never happen.

Free software and all the related libraries are not Linux-only, they are cross-platform and will have to implement different sound backends anyway.

Even if you get everyone on Linux running PulseAudio (which I don't believe), you won't have everyone on BSD, Solaris, and a number of other platforms. All libraries worth anything will have a Win backend, an OSX backend, an ALSA backend and an OSS backend. Now you're simply adding PulseAudio as yet another target.

If you think that GTK and Qt are going to drop ALSA and OSS, you're insane.