(In reply to comment #137)
> 2009/9/27  <email address hidden>:
> > 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?

Because JACK and in-kernel-tree OSS do not provide ALSA compatibility. Pulse does, but it's broken for the purposes of Wine. The solution is therefore to fix winealsa to be pulse-friendly, to not use pulse (e.g. pasuspender) or trick pulse into likeing Wine (e.g. padsp, which only works for some people). A separate pulse driver is not needed.

> 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.

Then use a system that works properly and doesn't hate Wine like ALSA's built-in dmix. Or don't use Wine with audio.

> 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. 

So you're saying Wine can never provide a satisfactory pulse driver because of limitations of pulse? On this point, we are agreed.

> 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.

If pulse is "officially" supported by Wine, then the implication is there that it will be suitable for the general-purpose nature that Wine has.

> > 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.
-- snip --
> 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 .

There is as of yet no demonstration that the ALSA driver cannot be reduced to the "pulse-safe" subset without compromising features or performance. I suspect this is the case, but if you have read the discussion, Wine's core developers require a definite and demonstrated (by code) NEED for a separate pulse driver before it will be considered for upstream.

> 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.

Enthusiastic developers have been known to disappear completely. "Someone is willing to maintain it" certainly goes in favour of the pulse driver, but does not satisfy the remaining objections.
 
> This is not an either/or situation. I don't see how it is helpful to portray it
> as such.

Because adding a new driver would probably lead to yet another half-complete unmaintained audio output driver in upstream, and the developers don't want that. So if it is possible (in code) to make the ALSA driver work nicer with pulse (apparently there has already been movement in this direction), then that is definitely the way to go.