[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

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

--- Comment #284 from Ben Klein <shacklein at gmail.com> 2010-12-09 05:19:58 CST ---
(In reply to comment #278)
> > In that case, Wine cannot officially provide support for Ubuntu users,
> > especially in light of the apparent removal of dsound support from winepulse.
> 
> Ubuntu and Fedora are the two most widely-used Linux distros, and this is the
> 4th-highest voted bug in the Wine tracker. Way to put your head in the sand!

This is a simple declaration of the current state. If pulse CANNOT be removed
from Ubuntu then AppDB and bugzilla posts from Ubuntu users CANNOT be
considered valid, (unless there is a very clear and definite non-audio related
problem).

> I don't care what you like or don't like, I care that Wine does not work
> properly unless I hobble my OS install or hack Wine - despite the fact that I'm
> using the latest official release of the most popular Linux distro.

So you don't care what I like but you care enough about what you THINK the
developers "dislike" enough to complain - no, bitch - about it?

> > > The only way one may take to get proper support of pulse in wine is ...
> > > out of the official wine tree.
> > 
> > This is not "proper support". Bug reports when out-of-tree patches are in play
> > are by definition INVALID, as are AppDB reports.
> 
> I'm not sure what you're on about there.

Then read it again. It's all there in plain English. WineHQ does not and cannot
provide any support for out-of-tree patches, therefore this is not "proper
support" but, at best, "functionality". It is not "proper" by ANY definition.

> You're right; it's Wine's fault for deciding not to give first-class sound
> support to the majority of end users,

Once again with the recrimination of Wine devs. What about the distros' who
decided to make it difficult or near-impossible to remove pulse? Are they not
to blame for effectively dropping any support to or from Wine develops?

> whether by working more closely with the
> pulseaudio team, or by taking winepulse under their wing, or by making the new
> OpenAL back-end a higher or more visible priority.

The first two have been tried and failed; the latter has already happened,
relatively speaking.

(In reply to comment #280)
> Ben Klein, you're trolling and lying and you've been trolling and lying in this
> thread almost since the times this bug had been submitted to bugzilla.

Normally this would not warrant a response. However, I have to endure
near-flame attacks like:
(In reply to comment #278)
> I'm telling you point-blank that stock Wine does not work properly on stock
> Ubuntu, and that's a problem no matter how you spin it. I'm sorry if you can't
> see that, but many other users care about it even if you don't.

This is NOT about what I care about, nor is it about what the users care about.
It is about the technical pros and cons for implementing/accepting a winepulse
driver, or alternatively making winealsa and wineoss more pulse-friendly, or
alternatively implementing a solid wineopenal.drv. See below.

> Your position is clear, position of wine devs is clear: "official Wine tree
> would not include pulseaudio subdriver". Wine userbase don't need your
> technical and whatsoever reasons why had this decision been made.

This is bugzilla. The technical reasons are the MOST important for describing
why a bug has not been addressed. Bugzilla is NOT a voting system for users to
say "I'm the 200th user to report this problem in 5 years. Why hasn't it been
fixed?"

Welcome to reality. I do not troll, nor flame, nor lie; I state the facts as I
understand them. This includes repeating and forwarding the intentions and
decisions of the developers as I understand them. I cannot speak for the dev
team, but I can provide some insight into their decisions, as I somewhat
understand the technical limitations and reasoning related to how they have
addressed this bug.

> The only result you would get is another portion of lies and
> we-won't-do-it-s.

See below for a "we-are-already-doing-it".

(In reply to comment #281)
> (In reply to comment #279)
> > do. So, hear me: there are *no* unresolved technical reasons for not being a
> > winepulse driver in Wine. It's all politics.
> 
> Thanks for the rational post.

Something is not rational simply because you agree with it.

> I decided to email Scott Ritchie yesterday to see if he knew anything about the
> status of the OpenAL-based replacement back-end, as I haven't seen any
> information on it for almost a year. Here's his response in case anyone is
> interested:
> 
> "It's kind of hard to say actually.  Maarten is the one doing the work,
> but he couldn't come to wineconf at the last minute.  Julliard has some
> doubts about OpenAL mainly because some of the tests are still failing
> after the partial implementation, but I'm not sure if that's a permanent
> thing."

As far as technical concerns go, OpenAL has to show that it can deal with low
enough latencies and buffering issues suitable for Wine's uses.

(In reply to comment #283)
> Yes it is about politics. But the world is changing over the years. Politics
> should react on changing facts.

The decision to not include winepulse has literally NOTHING to do with
politics. See below for the "we-are-already-doing-it".

> There are several major changes which should make Wine (aka Alexandre) rethink.
> 
> 1) It is now clear that PulseAudio is not just one more audio system but it is
> the mainstream audio system in LINUX.

False: ALSA is the SINGLE audio system in Linux, given that it is the only
non-deprecated soundsystem provided in the kernel. It must also be pointed out
AGAIN that pulseaudio DEPENDS on ALSA libraries (or the equivalent in other
systems), giving even more credence to ALSA being the mainstream system.

> Users simply want to plug in
> their device and it should work. When I hear music and a telephone call comes
> in the music should be muted etc. There simply is no alternative available
> which could serve all the required use cases better. 

This is actually something that I agree with. Pulseaudio has the feature set
for full Just Works(TM)-enabled "plug-and-play" functionality. However, this
does NOT make it any easier for Wine to include upstream support for pulse; the
technical difficulties still remain.

> All major Apps do now support PulseAudio at least good enough. Is it Skype or
> Flash or whatsoever. With one exception: Wine

Flash supports pulse by support of a kludge. Skype for Linux IS a kludge.

> PulseAudio is still not one for all, e.g. for low latency you should fall back
> to JACK

JACK is not "falling back". Straight ALSA is.

> but it fulfills the 99% usage.

So does ALSA's dmix. OK, maybe more like 95%.

> Professional audio users and hard core
> system geeks might not want to use PulseAudio.

... or ANY software mixer for that matter (I fall into this category).

> But for those it is acceptable
> to change or build their system the way they need it.

... which is not an option for the vast majority of laptop users.

> It is ridiculous to ask ordinary mainstream users to rebuild the hart of their
> system to use Wine with proper sound.

Pulseaudio is not the "heart" of the system, nor is it the "heart" of the sound
system; ALSA is on Linux systems.

> And it is ridiculous to wait for some magical fix of PulseAudio Alsa. This was
> discussed and this will never happen. It is technical nonsense.

winealsa has already shown marked improvements in performances when used with
the ALSA pulse plug. How far these improvements can go has, to my knowledge,
not been shown yet.

> 2) Wine is officially on release 1.0 and higher. Thus it is not a construction
> site for some freaks but a mainstream tool.

Something does not suddenly become used by a substantial number of people once
it hits an arbitrary version. The 1.0 release was mostly done as a reason for
the devs to be forced into fixing existing bugs rather than implementing new
features.

> Functionality is the key. As long
> total cost of development is in a acceptable relation it is more important than
> long term design issues.

At this point, you make perfect sense. The Wine dev team, AJ in particular, do
not see the cost of development to functionality ratio as being at an
acceptable level. However ... see the "we-are-already-doing-it" below.


(In reply to comment #282)
> I've been refraining, but here we go with more bug-spam.

Welcome back to the discussion, Art.

> (In reply to comment #277)
> Dsound is supported by the winepulse
> patch, just not by a faked dsound primary buffer but by emulation in
> dsound.dll, as it is for every other backend other than wineoss and winealsa.

I'm sorry I didn't have the resources to research this point before posting the
comment. I found it hard to believe that dsound support had been REMOVED from
the patch as Raymond in comment #267 suggested. I would like to apologise
specifically to you for the comment I made about fixing rather than removing;
you've now made it clear that it is exactly what you have done.

Now, for those of you with the patience to read my long posts ...
WE-ARE-ALREADY-DOING-IT from the Wine dev team, courtesy of Art Taylor:

> My read on the state of audio in wine is that winmm.drv (which implements the
> windows multimedia extensions originally from win16) will cease to be the base
> which drivers are written for once mmdevapi support in wine is complete. Thus,
> why bother including new winmm backends when you can patch the ones you have to
> still work until the next-generation support is finished.

In short: current winepulse will have to be rewritten ANYWAY, but we need the
new subsystem to be finished before the devs decide to include winepulse at
all. This is good news for EVERYONE, except the hypothetical person who is
especially attached to the existing winmm code.

I could probably get winepcspeaker included when mmdevapi goes live ...

> Especially backends written by comp-sci undergraduates ;-)

Your education is irrelevant; what are important are your talent and
dedication.

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