Linux is not ready for Steam

[kazetsukai]

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

Agreed. Pulse presents another bloated layer of stuff we'll never need in 90% of cases.

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?

I understand this viewpoint but you have to realize that there is a huge amount of work that went into ALSA to make it more or less universal. Having to go back and redo some of the nicer functionality will cost developer time and user frustration. Bluetooth audio, USB audio device support, A52 encoding and bitstreaming... alot has happened since OSS was "dumped" for ALSA back in 2002-2003. This work would all have to be redone to achieve feature parity.

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

With feature losses, this approach would save developers but hurt end users.

Ultimately Linux audio is in a very difficult situation with no easy and cheap solution. The best solution I can think of going forward would be to strip down and fork ALSA into a new branch- that way you could fix alot of the architectural problems while retaining alot of the nicer features, keeping users happy because they can fall back on legacy ALSA if they need the features not yet implemented in the newer versions.

Pushing OSSv4 into the main distributions would do nothing but cause problems, since you'll have two APIs fighting for the same hardware, or you will end up using an emulation layer which potentially creates all of the problems outlined in this thread anyway.

OSS is considered deprecated by many and there is alot of resistance to it showing up in newer distros for a good reason- it would be backtracking to a less functional state with no immediate or long term advantages. This is not even getting into the politics and (lack of) trust the Open Source community has for the architecture and its developers.

[darkphoenix22]

I just want to keep all options on the table. I would like to hear from the ALSA team how much time and effort it would take to integrate the functionality of PulseAudio directly into the ALSA API.

[darkphoenix22]

Summary:

Let's concentrate on getting PulseAudio removed from the major Linux distributions right now. It is impediment to game development on Linux as 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 tolerant of a bare buffer instead of direct hardware access will fail when using PulseAudio.

Removing PulseAudio is an immediate need.

Let's then concentrate on adding the features of PulseAudio to ALSA to rid Linux of all this incomplete wrapper mess. Probably, the best place to start is to extend dmix to support per-app volume controls.

[KDesk]

@darkphoenix22

What I realize is that you talk a lot, and do nothing.
You say all kinds of assertions without any justification or sources. Your own experience? Do you plan to convince somebody with that?
Repeating in almost every post that OSS is the way to go won't give you the reason, maybe it will convince yourself.

OSS4 in Linux has the fundamental problem of doing a lot of prohibited things in kernel like mixing, conversion, resampling, remapping, etc. It will not get accepted in the mainline kernel, so distributions will not make OSS4 default, it is irrelevant on Linux. Until they fix (how many OSS developers are there?) OSS so it can be merged and replace alsa, alsa will sure be fixed first.

Adding OSS4 to the distributions repositories won't make it better than alsa, also developers will not start fixing it, or can they not extract and compile OSS for them selfs?

You say that PA adds latency, of course! It is expected to happen. But do you know how much latency it is? And compared to Mac OS X/Windows 7? Did you know that if you move away from the microphone or speakers, latency increases as well?
How much is this compared to using Skype or a game with and without PA, with ALSA, with OSS?

Doesn't PA work for you? Have you thought it can be that your sound drivers are broken? Submitted bugs/patches? (not including trying to convince the Ubuntu developers with no evidence that PA is bad, OSS is better than alsa+PA?)

What makes you think that people don't use Bluetooth audio devices? If it is broken for you, it does not imply that it is broken for everybody. You should know this, as someone told you in the ubuntu-devel mailing list.

Why do you think that Red Hat, Mandriva, etc., pay the developers to write Pulseaudio and ALSA? Because they have a lot of money? No, because they want more money! They think that PA is the right thing that is needed.

Be sure that Valve knows better than many of us (and you) how audio works/doesn't work in linux, and which are there biggest targets (ubuntu, suse, fedora..). Otherwise they would not develop Steam/Source for linux. They know how to do this. Unlike Adobe with flash.

Summary:
Let's concentrate on getting PulseAudio removed from the major Linux distributions right now.

Who? You and yourself?

How many more "summaries" about the same do you plain to write?

[kaczu]

Just My 2 Cents

While I'm definitely not a developer I have been a linux user for quite some time. After reading all of the posts I felt that I wanted to at least offer my point of view from a generic end user.

Sound Server Latency

I don't know where this mythical no latency sound server has come from but they all add latency. Vista and Windows 7 both have sound servers and they add latency. This issue was actually a bug with Vista when other resources were being utilized (for some strange reason it came with network utilization). So I really don't see the point of going after Pulse Audio for this issue. It's inherent in the fact that your communicating with a driver stack using an API that's not low level.

Getting rid of PA?

As I said before I'm not a developer but I have used linux for quite sometime. While PA initially was a cluster it effectively brought feature parity with Windows (which actually means something if you're trying to port software). Not only that but I'm not so sure everyone is aware of the issues that existed without it. Why would an end user like turning down a flash movie only to have it turn down amarok too? Or play a game only to have it cut the audio in the mp3 you're listening to? This is not limited to one distro, before PA I saw similar issues in them all (and yes this is a fact). Those that don't use PA still have these issues.

I'm not going to lie to you there's still some problems of running applications which are written directly to ALSA, but those instances are quickly declining. I really don't understand the desire to strip it out again only to be left with all of the same issues or requiring the end user to edit asoundrc files. That's just not acceptable anymore.

Tear It Down, Rebuild, Replace

While tearing something down to make it better is a amicable thing and sometimes it is indeed necessary, there is an inherent problem with doing this ad nauseam. This discussion is a really good example of it. Doing this over and over again because a program doesn't agree with someone's sensibilities makes the "Linux is not ready for Steam" argument moot because it will never be ready because it will never coalesce around a standard.

Direct X 6 was a standard and it sucked in comparison to OpenGL at the time. However, why did it and later versions succeed? Because it was well documented, well supported, and ubiquitous (probably well "funded" too). This only comes from the ability to accept a standard at some point ......flaws and all.

Whether PA works around problems with ALSA via patch, hack, or playing with it's crack is irrelevant to the end user if it's reliable. It's irrelevant to producers (the people with the money) if the developer can actually produce a good product. and it's almost irrelevant to developers if the API's are active and well supported. PA might not be perfect but it solves some nagging issues and it's not dead, has support, and it's cross platform.

In closing this desire to immediately crucify any program/distro/binary that's popular has got to stop. Their popularity, or cause for use is due to it fulfilling a need, which was not being fulfilled and like it or not that means something. Steam hopefully is coming because it too, fulfills a need. As a community we should find ways to support it and not air our dirty laundry when we don't even have the detergent to clean it yet. Just my two cents.

[darkphoenix22]

As I said before I'm not a developer but I have used linux for quite sometime. While PA initially was a cluster it effectively brought feature parity with Windows (which actually means something if you're trying to port software). Not only that but I'm not so sure everyone is aware of the issues that existed without it. Why would an end user like turning down a flash movie only to have it turn down amarok too? Or play a game only to have it cut the audio in the mp3 you're listening to? This is not limited to one distro, before PA I saw similar issues in them all (and yes this is a fact). Those that don't use PA still have these issues.

I believe the best course of action is to add this functionality directly to ALSA, instead of through a wrapper. It has been suggested to extend dmix to provide the per-application volume controls,

I'm not going to lie to you there's still some problems of running applications which are written directly to ALSA, but those instances are quickly declining. I really don't understand the desire to strip it out again only to be left with all of the same issues or requiring the end user to edit asoundrc files. That's just not acceptable anymore.

The problems are still there with games and will always exist with games. This because games are programmed to expect direct hardware access, which PulseAudio does not provide. PulseAudio simply does not provide enough API functionality suitable for game development. Games rely on timing on every other operating system. Game developers are not going to break their back to support PulseAudio when such limitations are not present on other platforms.

I have never been required to edit .asoundrc files. Perhaps you need a better mixer. I recommend the Xfce Mixer.

[Remco]

The problems are still there with games and will always exist with games. This because games are programmed to expect direct hardware access, which PulseAudio does not provide. PulseAudio simply does not provide enough API functionality suitable for game development. Games rely on timing on every other operating system. Game developers are not going to break their back to support PulseAudio when such limitations are not present on other platforms.

Since Vista, Windows developers do not have direct access to the audio hardware. That is not the problem.

[chaperon]

This because games are programmed to expect direct hardware access, which PulseAudio does not provide.

This was the case in the DOS days, as for the myth of sync on sound output. Game developers expect a much higher level interface, which is usually an embedded software mixer that needs a plain low-latency stereo/5.1 output.

Games use RTC or internal timer for sync (sometimes vsync on specialized hardware) and I repeat : FMod and OpenAL are de-facto standarts, other engines do software mixing internally. This trend is linked to the fact that Microsoft removed 3D sound support in DX10.

To support steam or other games, all is needed is a good API for OpenAL/FMod software mixer, with minimum latency and jitter, minimum CPU usage and recording facility (for voice support). ALSA fits the description perfectly and OSS can do this, but I think PA has too high CPU usage for this task in low-latency configuration (maybe this will improve with time). A way to sync audio buffers to vsync would be definitely a plus (as this was the case in pre-Dreamcast hardware).

[pingufunkybeat]

As I said before I'm not a developer but I have used linux for quite sometime. While PA initially was a cluster it effectively brought feature parity with Windows (which actually means something if you're trying to port software). Not only that but I'm not so sure everyone is aware of the issues that existed without it. Why would an end user like turning down a flash movie only to have it turn down amarok too? Or play a game only to have it cut the audio in the mp3 you're listening to? This is not limited to one distro, before PA I saw similar issues in them all (and yes this is a fact). Those that don't use PA still have these issues.

No, we don't.

In fact, I didn't even know what PA was until about 6 months ago.

Mixing works fine here, and Adobe volume does not impact anything else on my system.

I'm aware that "works for me" does not mean that it works for everyone, but similarly, "doesn't work for me" does not mean that it doesn't work at all.

If per-app volume control is the ONLY thing that ALSA is missing, then we should add that to ALSA in a transparent way and be done with it.

It's sickening to see people calling for rewriting all Linux software to work with PA and PA only. Some of us don't run Ubuntu, OK? If you want to run it, please do, but don't force everyone to run a huge complex sound server just because some ALSA drivers have buggy mixing.

[kazetsukai]

It's sickening to see people calling for rewriting all Linux software to work with PA and PA only. Some of us don't run Ubuntu, OK? If you want to run it, please do, but don't force everyone to run a huge complex sound server just because some ALSA drivers have buggy mixing.

Not to mention that some of the Ubuntu variants (Kubuntu) don't install it by default.

ALSA needs to have a completely pipelineable architecture, which it currently lacks (certain types require direct access to the hardware rather than another generic type). I don't know about the ALSA developers, but I would consider that a very big, glaring bug. Per-app volume is a very minor feature request in comparison.