Comment 321 for bug 371897

(In reply to comment #215)
> winealsa has already been improved to work better with pulse.

No, that was tried, but it still doesn't work any better than it did before. (stutter, dropout, latencies)

> ALSA's OSS emulation doesn't have OSS4 features, and does not work
> with dmix, so software mixing while using ALSA's OSS is impossible.

You are confusing the kernel version of OSS emulation with alsa-oss - the whole point of the latter is that it works with dmix.

> What more can a pulseaudio proponent wish for?

A bit more of help & goodwill would be nice. Oh, and of course no "us against them"-labeling people "proponent". That would be great, too.

> (In reply to comment #214)
> > (In reply to comment #211)
> > > The argument is that there is no evidence that winealsa cannot be
> > > improved sufficiently to work well with Pulse.
> > > Until such evidence is presented, a separate winepulse driver is
> > > unlikely to be considered.
> >
> > It's impossible to prove non-existence. That's the most basic logical fallacy.
>
> Except that there is evidence [...]

You specifically asked for a proof of non-existence, see above.

> [...] that winealsa can be improved to work better with
> winepulse.

The only thing that there is evidence up until now (by fixes that _should_ improve winealsa compatibility with PulseAudio, but didn't) is that improving winealsa to work with Pulseaudio (not winepulse) isn't that easily possible.

> As soon as someone demonstrates the technical reasons why a separate
> winepulse is needed (and why you can't do the same things with an improved
> winealsa) [...]

Let's try it with a fun fact first: winealsa tried for over two years now - and didn't manage.

Now, here's the technical reason: A native sink is better than a compatibility sink.

> Except that it's perfectly possible for the use case of "get Wine to work with
> pulseaudio" to be done without requiring a separate winepulse.

"Everything is possible" is trivial, too:
That didn't happen for two years now. Perhaps it will happen, perhaps it won't.

The only thing that is certain is that winealsa (or wineesd) doesn't work _right now_ and winepulse does.

> It should be examined as a short-term solution for users.

It has been tried and found lacking. (heavy latencies)
And, of course, wineesd itself has no future as a native sink, so it's the wrong point to invest time into.