[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

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





--- Comment #137 from Neil Wilson <neil at aldur.co.uk>  2009-09-26 23:10:09 ---
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?

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.

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. 

>
> Another reason, as has been discussed, is that pulse adds unreasonable latency
> to be used as a general purpose software mixer (as in one that is suitable for
> professional applications).

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. Neither is anybody suggesting that Wine should default to the
Pulseaudio driver in the main installation. Distributions could make that
choice as required in their build configuration.

Professional level applications are likely to use JACK anyway. 

>
> 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. Altering the ALSA driver to work with pulse would
require that the ALSA driver work at the lowest common denominator and that all
the fancy twiddles you can do for a *local* sound card installation would have
to be disabled for Pulse due to its inherent remote nature. The alternative is
a complex mess where you're checking all the time what is going on - or the
current abstraction layer which fails when Wine ALSA asks for a 'fancy' option
that PulseAudio simply can't provide (like access to the hardware).

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 .

The alternative is that you have an ALSA layer that can assume it is sat
directly on ALSA all the time and can fully exploit the interface plus a
Pulseaudio module that does all the compromising - but keeping Wine informed of
the compromises so you don't get errors.

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.

This is not an either/or situation. I don't see how it is helpful to portray it
as such.

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