Wine Developers Fight Over PulseAudio Driver

[russofris]

Nope. All applications open a single device. Output to that device is then mixed together by dmix.

Are you certain? Then why does PA exist? I was under the impression that this was the major obstacle that PA was created to overcome. I distinctly recall having to mess around with my .asoundrc and creating multiple virtual cards in order to get two applications to playback simultaneously under Alsa, and to assign a volume to each individual application. This was some time ago though (2006-ish).

F

[Teho]

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.

I don't think so. PulseAudio is still the de facto audio server so supporting it as well as possible should be the top priority.

There's two approaches to fixing something. a) try to fix the existing code and b) rewrite the existing code. PA did neither. It just threw another API in there. So when something turns up in PulseAudio that doesn't work well in the future, let's create yet another one. We'll call it NewAwesomeAudio which replaces PulseAudio. And later, when problems with that turn up, we'll go for yet another new API.

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.

No. If there's a problem, fix it.

PulseAudio did just that.

[RealNC]

I don't think so. PulseAudio is still the de facto audio server so supporting it as well as possible should be the top priority.

I think this is one of the core issues. When you introduce something new rather than fix what already exists, you create a lot of pain. For years PA was wreaking havoc on user's systems. That was really a very bad situation. This shouldn't have happened.

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.

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.

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.

[RealNC]

Are you certain? Then why does PA exist? I was under the impression that this was the major obstacle that PA was created to overcome. I distinctly recall having to mess around with my .asoundrc and creating multiple virtual cards in order to get two applications to playback simultaneously under Alsa, and to assign a volume to each individual application. This was some time ago though (2006-ish).

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 :-/

[Teho]

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.

It's not that simple. We got the architecture right with PulseAudio so there is no need to start from scratch. The situation was quite different with ALSA. The ALSA APIs that PulseAudio is using are for controlling the hardware and are not something that other application developers would like to touch anyway. All the userspace developement has happened in PulseAudio and Jack for years now. Even if something could have been done differently six to eight years ago it's now distant past and quite frankly doesn't matter at all.

[benjamin545]

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)

[Vadi]

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.

[RealNC]

It's not that simple. We got the architecture right with PulseAudio so there is no need to start from scratch. The situation was quite different with ALSA. The ALSA APIs that PulseAudio is using are for controlling the hardware and are not something that other application developers would like to touch anyway. All the userspace developement has happened in PulseAudio and Jack for years now. Even if something could have been done differently six to eight years ago it's now distant past and quite frankly doesn't matter at all.

Reading the problems Wine has with PA in the link given in the original post of this thread, it seems doubtful that PA has indeed got the architecture right though.

[1c3d0g]

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.

[BO$$]

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?