Yes, though many users remove it. And since now you can create a setup where ALSA applications can be redirected seamlessly to PulseAudio, it makes more sense to support ALSA only. The PA API makes less sense now.
It does solve a whole lot of problems. But it does that using the wrong approach. The userspace part of ALSA should be doing that. Everything should be nicely integrated using a single API instead of two.
You're forgetting two points here. First of all, ALSA applications can't be seamlessly redirected to PulseAudio - after all, if that was the case, then we wouldn't need the PulseAudio driver for Wine in the first place. And from personal experience, if I use either ALSA directly or ALSA to PulseAudio to ALSA to record my microphone, the recording has so much popping sound that SoX refuses to process it; using PulseAudio directly produces crystal clear sound. So no, the process is not seamless at all, as the buggy nature of ALSA seems to do something wrong with the audio before PulseAudio takes over.
The second point is about APIs. Benjamin there gave a fairly good example. Furthermore, you must not forget that PulseAudio is in fact not strictly related to ALSA. It also accepts sound sent to all of the other sound systems - OSS, ESounD, Jack, etc. and as such acts like a very universal compatibility layer. And I think PulseAudio isn't even strictly limited to ALSA output, either, it's higher level than that. So its code is long-term, as even if someone was to create another implementation that is better than ALSA to replace it, PulseAudio code could be reused to work with that, too. So it's not a competing API, it's a central API.
The defaults chosen for PulseAudio may not be ideal, yes, but I think it's set to work fairly efficiently. It uses the new timer-based scheduling that has advantages over the interrupt-based one (I think it has something to do with power saving, but I'm not certain), but depending on your hardware it may not work correctly. And I assume that there is no real way, aside from user input, to determine whether it's working correctly or not with your hardware. Same with the resampling methods - sure, they could set the trivial method to be the default, and it would work on all hardware. However, that also means that you'd be getting the worst possible sound, even if most of the sound cards/chips can handle better resampling methods. So from what I can gather, PA uses efficient, while not perfectly safe defaults, and it's up to you to tweak them according to your hardware.
The horde of sh*t comment had me laughing but it's true. Linux is an eighteen wheel tractor-trailer at this point with all the reinventing the wheel it does.
To the guy with the heavy load... The only time my sound ever dies is when I am writing DVD structures to disk and it's momentary at best so I don't know what you're doing but it's probably more intensive that whatever you do on your Windows OS either that or the player you're using buffers further on the Windows OS (since I am assuming disk i/o). As far as a CPU choking on audio you would have to be running a 10 year old single core.... or pulse audio.
Seriously though, I always had sync issues with pulse.Now I just use alsa and haven't had any issues.
...For Linux to move forward, there's got to be a consensus on this very basic functionality. Fork if you need to, but not because of meaningless differences. Fork because the underlying tech is truly different, innovative or disruptive. Right now we've got a hoard of shit doing basically the same thing. This it truly very sad.
The consensus is ALSA is already catered for in Wine, simply now add PulseAudio and let people choose. Personally I want Wine to run with other desktop applications without the sound dying. Yeah people will say OSS or ALSA already do multiplexing, but for me that has always been a problem. I've got zero problems with PulseAudio though, once you configure your whole system to default to it. Btw, I use KDE with gstreamer.
There should be no competition. There should only be one API. Top layers should be things like SDL, OpenAL, PortAudio, stuff like that. Third-party low-level APIs like PA should not exist. The existence of PA is proof of Linux's failure in audio.
The very notion of "third-party" on Linux is mistaken. Everything is third-party... well, maybe except for the Linux kernel and the GNU software collection, depending on your definition. Even ALSA userspace is third-party. Talking about "it's not built-in" is nonsense. PA is as much first-party as any other piece of the infrastructure on any distro that integrates it properly.
There's one "hw" device for exclusive access, and there's a dmix device that I guess you can call virtual. The hw device can only be opened by one application at a time. The dmix device can be opened simultaneously.
Per-application volume is not supported well. There's no automation for it, you need to set up everything manually and assign mixer controls to specific applications, which is totally useless. It's one of the things PA chose to replace instead of fix. Well, it was to be expected I guess. Linux devs usually want their own projects instead of joining an existing one. Fame and honor and all that :-/
That's (along the lines of) what I thought. If a per-application mixer can be allocated manually, I'm certain that someone could extend the API allocate them dynamically. Unfortunately, if I remember the formatting of the .asoundrc and the options for each dmix device (define inputs, outputs, sample rates, etc), it's going to be a big task.
Someone should look at the PA API, and reimplement the PA API on top of dmix (or extend the ALSA API). If it didn't work out, at least it adds some fuel to the fire that appears to be consuming the issue. Some bridges are better off burnt.
I haven't really been a fan of Miguel de Icaza's work since Rage Against the Machine broke up.
I seriously think the NAY SAYERS are on Pentium 3's or the like struggling to keep their system from dying and watching screen page flip.
Modern Linux users want Pulse Audio.
I would agree with you unnecessary CPU consumption was PA's only problem. My system is modern, I don't use it. Not saying other shouldn't just saying you're off on your statement. With that being said, I do think wine should be able to handle it if nothing else. I don't really like the idea of wine having a default I guess.