I believe that the correct approach would be to implement all the stuff in the ALSA library, simply because it avoids having two distinct APIs, controlled by different people. If the core functionality is in ALSA, all you need are simple GUI tools for configuring that functionality.PulseAudio takes radically different approach to the problem than ALSA so just rewriting stuff isn't possible. I still don't understand why you think that ALSA API is the end of all Linux audio APIs. I mean seriously even if ALSA was extended so far that it would resemble the PulseAudio we have now its APIs would have probably changed completely anyway.
But the base argument is really simple: if a problem turns up in PA, should we replace it again instead of enhancing it? I say no. You seem to say yes.
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 :-/
to anyone that doesn't really understand the alsa pulseaudio debacle, first put this in your mind, its not pulse vs alsa, its pulseaudio(or pulse for short) vs dmix. anyone who doesn't make this distinction is not quallified to discuss it.
ok. so, alsa is, like mesa, a name we give to a project that includes several related componants of the audio stack. theres the hardware drivers (this is what alsa normaly is reffering to), there is libalsa (an api used to actualy send the audio data to the hardware) and then there is dmix. pulse only repalces dmix, and it kinda replaces libalsa in a sense but not really. see, it use to be when you wanted your program to output sound, you would use the libalsa library directly. libalsa represents the hardware pretty much exactly how the hardware is designed. this is bad, because when you swite a program, you just want the sound to sent to the hardware, you dont care about how the hardware works. you might care about higher level concepts like ho many channels does the audio stream have or whats the bitrate, but you dont care about how the hardware works, or what limitations it may have orwhatnot. so the alsa devs kinda made some of the libalsa api kinda generic so that software devs could actualy write software to it. this ment that a simple 2 channel output was pretty standardized but any fancy stuff was often problomatic. also, no mixing if the hardware didnt support it. most hardware doesn't so obviously it sucked at that time. so they were quick to come up with dmix. dmix basicaly emulated a simple mixing sound card. in the alsa configuration file you would have your default audio output, whitch normaly redirected you to your main audio card, now it would output to the fake dmix device, then the dmix device would output to your main sound card. it worked, but it had its flaws. one, programs that made extensive use of the low level libalsa library functions, like wine, could easily hog the output and negate dmix alltogether. aldo dmix didnt use quick algorithms and ras pretty limited to basic functionalty coverage. also still you had end user applications and their high level auio api's (openal, sdl, gstreamer) using libalsa directly. it is for these reasons that dmix is a very good example of a hack, it worked but it had no long term value.
what pulseaudio did was come in, and replace dmix, and replace libalsa as a high level api (kinda they have a pulsealsa plugin to provide a cut down libalsa that satisfies most programs that only output through libalsa). now a program will use a high level api such as gstreamer, that will use libpulse to talk to pulseaudio, who will mix the stream with any other current output streams and pass it allong to the next link in the chain whether it be throguh the entowkr to another computer or right on through to the hardware. pulseaudio will talk to the hardware through libalsa, that means that pulseaudio will take care of preping the output stream to match the hardware. since pulseaudio is a project that compleatly focuses on the middle layer, it pretty much spent a lot of time on making a super efficient mixer. it has various options of how well or how fast you want the mixer to operate, it was designed as a zero copy mixer, meaning it doesnt copy the streams around, only one instance of the stream data is ever stored in memory, and it is also designed around liboil, a library that allows pulseaudio to mkae use of the risc additions of your proccessor (like mmx, or sse) to speed up parts of the mixing.
saying something like programs should talk to libalsa directly like they did before is really akin to saying programs should talk to libdrm directly(thus bypassing opengl, mesa, gallium3d, X)
Hm, I hope they clear this misconception up about the second driver. I as a user in the end just want to stop having to do "pulseaudio -k" every half hour while playing a game in Wine and restarting it as well, because the audio chokes up and dies on a lot of simultaneous sounds being played.
Jesus, the audio people are worse than the graphics peeps! Can't we get these 2 basic features (audio & video) under control? Is it really so difficult that people can't decide on a uniform way of producing sound of Linux without resorting to "MINE IS BETTER THAN YOURS!1!!!1!" mentality? Ridiculous.
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.
When my system is under heavy load I notice that if I listen to an mp3 it starts stuttering or even pausing completely until the hdd usage goes down. Under windows, under heavy load, I don't get that behavior. Who should I be insulting? PulseAudio or something lower level like the driver in the kernel?