Linux is not ready for Steam

[Mo6eB]

Also, regarding latency: I cannot detect audible sound latency while playing StarCraft. Running in VirtualBox. Which is configured to use the ALSA sound driver. So the sound goes like this:

StarCraft's own mixer->Windows XP sound stack in a VM->ALSA's pulse plugin->pulseaudio sound server->ALSA hardware driver->my soundcard.

It's totally fine. Claiming that a stupid game needs the same low-level latency as a professional audio workstation is pure hubris with no grounds in reality.

[IsawSparks]

Agreed. Also claiming that games use audio a timing function sounds very doubtful overall. I'm sure that a spare few examples could be brought to light but as audio is always underbudgetted in professional game development with the spare few exceptions of SQUARE/ENIX, Rockstar and the Rockband/sellmesomemoreplasticinstrumentsplease schools of development it's highly likely that most game devs take their timing functions from the core of the system, the CPU.

Even the award winning and much lauded Half Life 2 Source Engine in Windows had awful, grating looping and stuttering audio issues for the better part of 5 years since its release and while people did indeed complain that game and all of its Source driven products sold in truckloads.

In my opinion Pulse is about the most mature Linux audio solution we've ever had. No frigging around with config files, no need for third party mixers and all of my devices (AC3, Stereo In, Stereo Out, Bluetooth Audio) just work. People just are annoyed at how unstable it was in Ubuntu 7 and 8 but that was poor implementation for the most part and these days it's a dream to use.

Latency in Pulse is pretty much a non issue.

[kaczu]

Well I've got tonnes of openSUSE systems 11.1 and 11.2 utilizing various sound cards ranging from x-fi's, Cmedia 8788 based cards, and just plain on board systems. Like pingufunkybeat says no issue with mixing. In 11.1 the biggest issue was continuing to install pulse by default. The fix was to remove pulse and life was good again. In 11.2 it is only installed by default on Gnome systems. Sound issues dropped so drastically in 11.2 (at least in KDE land) that the old resident sound guru over at suse forums (oldcpu) had to look at a new subject to aid in troubleshooting in as he felt unneeded anymore. All that without an .asoundrc residing in the users home directly. If you had issues it was more then likely with 11.1 or 11.0 with pulse enabled.

So at this point aside from Gentoo, Arch maybe, which distros don't include it by default?

[pingufunkybeat]

Despite that you think I'm just talking about Ubuntu, Fedora also uses PA and for a lot longer than just 6 months ago.

And many other distros don't.

And using PulseAudio is not a problem. Having it as an option is not a problem. I guess it's useful for some people, and power to them. Shoving it down everyone's faces and crippling existing applications to not work with the NATIVE sound architecture is a problem.

So far, I haven't even known that PulseAudio exists, and when I found out about it, I disabled it in my USE flags and forgot all about it. If the "preferred" solution now is to cripple all Free software to not work anymore unless I install PulseAudio in order to solve "problems" which don't exist, then I have a problem with it.

The last time I tried it in OpenSuse 11.1 or 2 I think this was still a problem. Also have you made any edits whatsoever to the sound system to resolve any issues?

I haven't touched any of them.

This is on Gentoo, where you are actually expected to touch configuration files as a matter of principle.

Why add it to ALSA if PA already provides it?

Why use PA if JACK provides it?

Because people shouldn't need to run an extra sound layer for very basic functionality?

Because there are sound cards that do hardware mixing and you should let them do the hardware mixing?

This has absolutely nothing to do with Ubuntu. However, how about we'll have every developer write their own stack to every single whim for every single linux user who doesn't like ALSA, but likes OSS, maybe another set of instructions for those who like ALSA, maybe another set for those who like PA. Yeah that will make us receive tons of developer support.........except that doesn't work which is the issue I'm getting at.

Who writes exclusively for OSS nowadays? In any case, such corner cases work with ALSA too. I don't have a single program on my system that only works on OSS, and this includes proprietary stuff like Doom3 and Quake4.

At this moment, every single Linux app works with ALSA. I don't see the need to reprogram all of them to use PulseAudio exclusively (as advocated by some people here), just to punish people who aren't using it. Ultimately, you will have software written for ALSA, running through emulation over PulseAudio, having it resampled, mixed with another stream (silence in 99% of the cases), resampled again, and outputted back to ALSA for playback.

All this on hardware which maybe supports hardware mixing in the first place, and none of this is necessary.

I'm not saying that PulseAudio does not serve a purpose. Perhaps such a solution really is needed for the future, considering the bluetooth cases people have mentioned or usb plug and play, etc. I don't know, I'm willing to be convinced that this is the correct way forward and that an ALSA patch wouldn't fix the same problem much more efficiently and elegantly.

But don't come to me with software mixing FUD that is easily checked by anyone with access to a sane distribution, and stories about per-app-volume. If per-app-volume is the killer argument, then I really don't accept that you need a whole new professional sound infrastructure with 1,000 new professional features running as a daemon over ALSA to do such a trivial thing. That's an abomination.

[b15hop]

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.

Who uses pulse audio anyway? Stick to Alsa, OpenAL or SDL.

I think too much diversity causes babble. Imagine everyone decides to write their own English dictionary. Or even restructure grammar so that it only makes sense to them. This is a typical problem that will always haunt Linux. This is why wiki can't be trusted at university level, even though so many people use it. Much like game developers can't expect to write professional code in python. Instead they use a real language like C or C++. There is a reason why some things are difficult. No pain no gain.

In saying that I also believe that releasing a buggy version of steam to Linux will be much worse than simply NOT releasing steam at all. Let alone all the implications of a Linux based Source engine. I mean surely if it's ported to Mac it can be ported to Linux. I'm getting impatient already and I'm sure a lot of other people out there are too! I can't believe I'm saying that I want steam, since I'm completely against steam all together. Windows or not. My reason? Well if it helps the gaming front for Linux and helps swing an improvement in drivers, then so be it! They both need each other. No point having these lovely drivers and no way of using them. What comes first, the chicken or the egg....?

[deanjo]

So at this point aside from Gentoo, Arch maybe, which distros don't include it by default?

Since KDE is the default desktop in openSUSE now you can include openSUSE as one of those distros that don't install it by default.

[b15hop]

GRR BLASTED NO EDIT POLICY!

Release STEAM now. Or forever be labelled dreamware or vaporware. Duke nukem forever...... and ever.....

Source engine released to an Open Source platform. Ironic.

To requote what I said, I believe that an early release of steam would be good. Strike while the iron is hot. Another year might be the difference between half of those source games being played and forgotten about. SC2 is just around the corner. That should be released on Linux simply from the fact that there is a Mac client.

[pingufunkybeat]

I'm pretty sure that Slack does not include it by default either.

It seems that distros only include it by default because of GNOME's dependence on it.

This will ensure that multimedia software packages add a PA backend, but I don't expect MPlayer, VLC, Amarok and the rest to drop ALSA support.

[mugginz]

Despite that you think I'm just talking about Ubuntu, Fedora also uses PA and for a lot longer than just 6 months ago.

And many other distros don't.

And using PulseAudio is not a problem. Having it as an option is not a problem. I guess it's useful for some people, and power to them. Shoving it down everyone's faces and crippling existing applications to not work with the NATIVE sound architecture is a problem.

So crippling the sound system by removing PulseAudio is the answer?

So far, I haven't even known that PulseAudio exists, and when I found out about it, I disabled it in my USE flags and forgot all about it. If the "preferred" solution now is to cripple all Free software to not work anymore unless I install PulseAudio in order to solve "problems" which don't exist, then I have a problem with it.

Lucky for you those problems obviously don't exist on your own particular system. Not everyone's so well off.

Why add it to ALSA if PA already provides it?

Why use PA if JACK provides it?

If JACK provides the same feature set and is as compatible with software as Pulse is and is available, ready and pre-packaged to provide this then there's no reason not to use JACK.

Because people shouldn't need to run an extra sound layer for very basic functionality?

ALSA routes the PCM data through a software mixer as well. You still have latency addition whether using Pulse or ALSA.

Because there are sound cards that do hardware mixing and you should let them do the hardware mixing?

And there are sound cards that don't do hardware mixing. As well as that, what happens when you max out the amount of channels available to a particular card that does? Add another card?

This has absolutely nothing to do with Ubuntu. However, how about we'll have every developer write their own stack to every single whim for every single linux user who doesn't like ALSA, but likes OSS, maybe another set of instructions for those who like ALSA, maybe another set for those who like PA. Yeah that will make us receive tons of developer support.........except that doesn't work which is the issue I'm getting at.

Who writes exclusively for OSS nowadays? In any case, such corner cases work with ALSA too. I don't have a single program on my system that only works on OSS, and this includes proprietary stuff like Doom3 and Quake4.

At this moment, every single Linux app works with ALSA.

Every Linux program might be written to the ALSA API, assuming that ALSA automagically set itself up for the particular hardware in use and while that particular program's the only thing happening at any given time it might be completely happy. That's not always the case.

I don't see the need to reprogram all of them to use PulseAudio exclusively (as advocated by some people here), just to punish people who aren't using it.

Yes, we need users to experience more pain, just cause.

Ultimately, you will have software written for ALSA, running through emulation over PulseAudio, having it resampled, mixed with another stream (silence in 99% of the cases), resampled again, and outputted back to ALSA for playback.

Why would it need to be resampled the second time. Why wouldn't it be:

Software written for ALSA -> ALSA Layer for PulseAudio -> resample -> mix with any other audio currently playing -> Hardware.

All this on hardware which maybe supports hardware mixing in the first place, and none of this is necessary.

And maybe that hardware doesn't support hardware mixing. What then?

I'm not saying that PulseAudio does not serve a purpose. Perhaps such a solution really is needed for the future, considering the bluetooth cases people have mentioned or usb plug and play, etc. I don't know, I'm willing to be convinced that this is the correct way forward and that an ALSA patch wouldn't fix the same problem much more efficiently and elegantly.

But don't come to me with software mixing FUD that is easily checked by anyone with access to a sane distribution, and stories about per-app-volume. If per-app-volume is the killer argument, then I really don't accept that you need a whole new professional sound infrastructure with 1,000 new professional features running as a daemon over ALSA to do such a trivial thing. That's an abomination.

Pulse is performing needed tasks and then routing it to the hardware via ALSA drivers, just like the upper layers or ALSA do.

[pingufunkybeat]

So crippling the sound system by removing PulseAudio is the answer?

"The sound system" does not include PulseAudio on many systems.

You are free to use it if you wish. I should be free not to use it and disable it without crippling my system.

The fact that you can't simply turn the thing off in some distros is rather scary.

Lucky for you those problems obviously don't exist on your own particular system. Not everyone's so well off.

I understand this and agree.

But this is a case of buggy drivers, and bugs should be fixed, not worked around.

ALSA routes the PCM data through a software mixer as well. You still have latency addition whether using Pulse or ALSA.

Not if your card supports hardware mixing, you simply don't use a dmix plugin in that case.

Correct me if I'm wrong.

And there are sound cards that don't do hardware mixing. As well as that, what happens when you max out the amount of channels available to a particular card that does? Add another card?

Use a software mixer, which has been a part of ALSA for a long number of years. No need to use software mixing if your hardware supports it.

It's a bit like insisting on using CPU for 3d rendering, in case some cards have buggy drivers.

Terrible analogy, I know...

Every Linux program might be written to the ALSA API, assuming that ALSA automagically set itself up for the particular hardware in use and while that particular program's the only thing happening at any given time it might be completely happy. That's not always the case.

Once again, I have never had problems with any number of programs using ALSA simultaneously.

If this doesn't work on some systems, it's a driver bug.

Why would it need to be resampled the second time. Why wouldn't it be:

Software written for ALSA -> ALSA Layer for PulseAudio -> resample -> mix with any other audio currently playing -> Hardware.

If the first resampling is done at the correct frequency, then yeah. Still, it's a longer chain.

And maybe that hardware doesn't support hardware mixing. What then?

Then use software mixing, as present in ALSA for many years.

You only use it when you actually need it.

Pulse is performing needed tasks and then routing it to the hardware via ALSA drivers, just like the upper layers or ALSA do.

If it does exactly the same thing that ALSA does, then I really don't see the point.

ALSA was extended in order to kill ESD, which was doing pretty much the same thing as PulseAudio (though not as sofisticated). ALSA killed ESD. Now PulseAudio is here as a drop-in replacement for ESD.

The argumentation is that ALSA does not work correctly on all systems.

Is the solution to fix ALSA, or to introduce yet another layer, which works on top of a broken system, and introduces a whole new batch of problems?

Sometimes Linux really goes around in circles. People hated ESD and aRts because they introduced all sorts of problems with all sorts of applications and because there were all sorts of problems with backwards compatibility. In the end, they both died because of this. Now PulseAudio is pushed as a standard, and people are having the exact same problems again.