Linux is not ready for Steam

[pingufunkybeat]

Bingo! And This is not an option to lots and lots of people.

Editing config files in this area indicates fail.

And the correct option is having Flash crash for years?

What about gamers using in game chat via headsets

In Linux?!??

[pingufunkybeat]

Though if some commonly required functionality was needed though and it was implemented in a shared library until the driver implemented it natively then that'd make sense.

SDL is a shared library. It works with a number of backends.

PulseAudio is a daemon.

[mugginz]

Maybe my problem is with a sound daemon.

Every sound daemon in the history of Linux has always sucked. Things got fixed and improved, and they still sucked. And it seems like PulseAudio sucks too, given the number of problems people are reporting.

ALSA is not perfect. Perhaps it is stagnant as a technology, and ready to be replaced in order to deal with the new needs for a brave new desktop, bring more plug and play, etc. Perhaps parts of ALSA should be replaced by better code from a different project, and maybe PulseAudio has some of the answers. Maybe a library superior to ALSAlib should replace it, I don't know, I'm not against progress. Technologies such as hal and devfs have been abandoned and replaced by better things once they went stagnant, and maybe it's ALSA's turn for a major overhaul.

But introducing ESD 2.0 as a solution to software mixing is really not very convincing. We've seen this SO many times, and it sucked every time.

Fix the sound properly. Keep the hardware stuff in the kernel, and expose a sane API to the applications. In other words, reinvent ALSA if necessary. The apps should shove a stream into a device and not care about anything else.

Why do you need a daemon? Then if the daemon is not running, you get no sound? What sort of a Frankenstein solution is that?

If you have to provide shared access to hardware then that has to be arbitrated somewhere.

Some types of code aren't allowed in the kernel. Maybe they're now completely happy to accept floating point there.

Another thing, it's nice to keep the kernel foot print as unexposed to certain things as possible. A crash in the daemon shouldn't bring down your whole machine. A crash in a driver is another thing.

As a concept, I've no issue with a sound daemon. If a particular implementation sucks it should either be fixed or replaced. Initially I was thinking WTF, not again when Pulse was announced. I'm now sold on it personally.

It's now matured to a level I'm very happy with. The same couldn't be said a couple of years ago.

On the other hand, if the ALSA project achieved feature parity in a better way than PULSE then you've got a better argument.

[mugginz]

And the correct option is having Flash crash for years?

Thankfully Flash has native Pulse support in the 10 series.

In Linux?!??

Stranger things have happened.

[mugginz]

SDL is a shared library. It works with a number of backends.

PulseAudio is a daemon.

And that daemon arbitrates access to hardware on behalf of those shared libraries.

[blacknova]

I'm not sure for which of low-level sound system would be better feature wise OSS or ALSA. Judging from API simplicity OSS is much easier to program for.
But I belive this doesn't really matter since some kind of wrapper would be used on top of them anyway.
Another thing is desktop's sound server be it PulseAudio, ESD, Arts or any other newly invented, unlike many others here I don't think it is something absolutely evil and unnecessary.
Benefits of sound server are:
1. No need for complex low-level sound system (i.e. no software mixing,no data conversion )
2. Simple API
3. Possible network transparency for remote desktops usage cases (if all desktop applications are using sound server, I'm sure it is possible to do with OSS and ALSA directly with some kine of loop back driver, but that would add unnecessary data round-trip)
4. Simple configuration (for novice user, just need to select audio device, configuring default output device with alsa could need manual config editing)
5. Latency issues could be hidden with sound server operating at high priorities.

[darkphoenix22]

The problem is ALSA, as it stands, is too comphensive and complicated to allow for an effective wrapper.

If we want a sound daemon that will universally work, we need a simpler sound API.

PulseAudio/ALSA is not a solution, as PulseAudio does *not* allow access to the entire ALSA API.

[darkphoenix22]

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.

[energyman]

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.

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.

[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.

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-works-linux-audio-explained