[Bug 10495] Wine should support PulseAudio

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Dec 8 11:02:51 CST 2010


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

--- Comment #279 from Ove Kaaven <ovek at arcticnet.no> 2010-12-08 11:02:43 CST ---
> The fact of the matter is it's not simple or it would have been done years ago.

...which, in fact, it was.

Listen, Ben Klein, that's enough. I was a respected Wine developer years ago.
*I* once tweaked all these audio drivers to have decent performance, where they
didn't before. *I* once wrote code to make wineoss and winealsa dsound-capable,
where they once weren't so hot. Even now, I would be able to whip up a pulse
driver in a jiffy, except it has already been done, and I have better things to
do. So, hear me: there are *no* unresolved technical reasons for not being a
winepulse driver in Wine. It's all politics.

Now, I understand the political arguments. I understand the code maintenance
concerns, the design issues, the feeling that the current audio subsystem has
become an abomination. I understand that and I even agree. It's perfectly
understandable to me that they don't want to make the monster grow further by
adding yet another driver to the legacy design, and would rather rewrite the
subsystem first, in order to get a more streamlined and maintainable design for
the future. I don't have a problem with that. I understand why they'd be
happier to stick with pulse's alsa emulation, if it would just work. Why they'd
rather force someone to bang that alsa emulation into working if necessary,
rather than prolong the pain of maintaining the current subsystem.

Alexandre Julliard has, indeed, employed such measures in the past - i.e.,
sometimes he'd rather force people to rewrite parts of Wine before allowing
them to add features on top of those parts, if he thinks those parts are flawed
in some way. In such cases, the technical merits of the new feature isn't the
reason for his rejection - it's just his way of getting people to do more work
for Wine. Before a Wine contributor can scratch his/her own itch, Alexandre
might make sure he/she scratches someone else's related itch first - or at
least doesn't cover that other itch up so much that it'll never be scratched.

I won't push for the inclusion of winepulse in its current incarnation.
However, I *do* have a general problem with people who aren't telling the
truth. The reasons for not including winepulse are *not* technical, they are
code policy decisions (and probably fairly good decisions, at least from
certain perspectives, but nevertheless undeniably political). So, stop
spreading lies, stop acting like you know what's going on, and stop berating
users that are seeing right through you. What these users want is perfectly
reasonable, and even if there may be good political reasons not to give them
that quite yet, they don't deserve being flamed by someone parroting obsolete
arguments that were only half-true even when they were new. I think they have a
right to actually know what's going on.

There's no technical reason for winepulse's non-inclusion. It's all about a
line in the sand. A piece of less forward-thinking engineering within Wine
itself, that Wine developers don't want to see grow more arms. I'll even take
some of the blame for propagating that design myself, back when I could have
done something about it and perhaps should, but didn't, and instead probably
just made it worse. A little piece of this mess is *my* fault. And now people
have to suffer for that. That's the way of politics, good or bad. At least,
it's certainly not about any technicalities of the winepulse driver itself.

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



More information about the wine-bugs mailing list