[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10495





--- Comment #215 from Ben Klein <shacklein at gmail.com>  2010-02-13 15:15:31 ---
(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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.