[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

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





--- Comment #138 from Ben Klein <shacklein at gmail.com>  2009-09-26 23:33:53 ---
(In reply to comment #137)
> 2009/9/27  <wine-bugs at 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?

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.

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