Comment 320 for bug 371897

(In reply to comment #212)
> (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.
> This argument is about as much bs as possible.
> 1) noting seems to have moved forward in this direction although I remember
> various changelogs claiming better support for alsa-pulse in the changelog. So
> either it would be really hard to fix or the wine-alsa code is just too ugly to
> look at so nobody dares to touch it.

"Nothing seems to have moved forward except those things that have." winealsa has already been improved to work better with pulse.

> 2) if your argumentation is true, why is there an wine-alsa in the first place?
> alsa also has a wrapper for OSS. has anybody ever "programmatically proven"
> that this is not compatible?

Yes, it has. 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.

> 3) there is a perfectly working solution (for me) with a maintainer and
> everything. what more can an open-source project wish for?

I've asked the maintainer to consult the wine-devel about what needs to be done to get his patch merged upstream. What more can a pulseaudio proponent wish for?

(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 that winealsa can be improved to work better with winepulse. 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), this objection will disappear. So far, the best I've seen is "winealsa is allowed to use stuff pulse's ALSA layer doesn't support", but no indication of whether it actually needs to or not.

> (In reply to comment #203)
> > I will continue to object to peoples demands that "Wine must support
> > pulseaudio" (or more specifically this particular patch set) based on the ad
> > populum fallacy.
>
> When it comes to Use Cases, there is no ad populum fallacy like you try to
> claim.

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. It's not for the average user to decide what drivers Wine includes upstream. It's not for me to decide either.

> (In reply to comment #211)
> > winesd
>
> ESD is dead. It has been deprecated by PulseAudio. Stop beating a dead horse.
> The backwards compatibility of PulseAudio to ESD is not the longterm solution.

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