http://bugs.winehq.org/show_bug.cgi?id=10495
--- Comment #137 from Neil Wilson neil@aldur.co.uk 2009-09-26 23:10:09 --- 2009/9/27 wine-bugs@winehq.org:
The main reason why Wine doesn't have a pulse driver in upstream is because it doesn't need one. We have tools like padsp or aoss that work for some people and pasuspender for everyone else.
Why are the JACK and OSS drivers needed then? By that argument they could be stripped and the whole sound driver selection dialog could be removed. Surely, if your argument holds, there is a whole batch of simplification that could take place. Why not do that if a single ALSA driver is the one true path?
pasuspender always seems like a good answer until your softphone fails to ring because your ALSA layer is locked out and you miss an important call.
The truth is that the Wine ALSA layer drives ALSA hard. Much harder than Pulseaudio's abstraction layer can ever provide. That generates an impedence mismatch that results in skips and broken streams.
Another reason, as has been discussed, is that pulse adds unreasonable latency to be used as a general purpose software mixer (as in one that is suitable for professional applications).
Last time I looked you could select which audio driver you require. Nobody is saying remove the ALSA driver or requiring that 'professional' applications use Pulseaudio. Neither is anybody suggesting that Wine should default to the Pulseaudio driver in the main installation. Distributions could make that choice as required in their build configuration.
Professional level applications are likely to use JACK anyway.
Furthermore, no one has proven that a pulse driver is actually NEEDED. The preferred solution is to modify, if possible, winealsa and/or wineoss drivers to work nicely with pulse. In this case, a pulse driver would *never* be needed.
The proof is straightforward. Altering the ALSA driver to work with pulse would require that the ALSA driver work at the lowest common denominator and that all the fancy twiddles you can do for a *local* sound card installation would have to be disabled for Pulse due to its inherent remote nature. The alternative is a complex mess where you're checking all the time what is going on - or the current abstraction layer which fails when Wine ALSA asks for a 'fancy' option that PulseAudio simply can't provide (like access to the hardware).
In other words the ALSA driver would have to be compromised to support Pulse, either in capability or structurally. That is unnecessary code coupling that would affect those users who want a clean ALSA driver .
The alternative is that you have an ALSA layer that can assume it is sat directly on ALSA all the time and can fully exploit the interface plus a Pulseaudio module that does all the compromising - but keeping Wine informed of the compromises so you don't get errors.
Plus pragmatically we have somebody who is interested in maintaining a Pulseaudio layer and apparently nobody who is interested in maintaining the ALSA layer beyond keeping the existing system running. That ought to count for something.
This is not an either/or situation. I don't see how it is helpful to portray it as such.