[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

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





--- Comment #211 from Ben Klein <shacklein at gmail.com>  2010-02-13 09:19:44 ---
(In reply to comment #210)
> (In reply to comment #203)
> > You could equally that it's pulse not supporting Wine, and that the bug is
> > pulse's issue. 
> 
> No. Pulse is down stack from Wine. Wine does not support outputing to Pulse.
> There is no point in even arguing that.

But Pulse could, in theory, be improved to work better with Wine. This was
discussed between Wine devs and Pulse devs long ago, and resulted in Pulse
telling Wine that "you're doing it wrong".

> > The absolute need
> > for a separate winepulse has not been programatically demonstrated
> 
> The need for Wine-pulse has been demonstrated much more than the need for Wine
> itself. By your logic Wine should not exist - there are better implementations
> out there and they are still used. And if you install Windows in Virtualbox it
> will also work.

What other implementation of win32 for *unix-based systems* are there? Do they
work better than Wine? Pulse is a cross-platform audio solution, so is OSS
(however OSS support is limited on Linux due to licensing issues, so ALSA is
generally preferred). Wine is an implementation of win32 (and some win64) that
is specifically designed for unix-like environments. You have to at least stay
close to the paradigm for comparisons like this.

> Your argumentation is absurd and is based on personal opinion only and yet you
> demand you opposition to provide dissertations to prove to you our point.

No, my argument is based on technical objections, the details of which do not
belong on Wine's bugzilla.

> The rejection of PulsAudio Wine driver has not been technically proven nor has
> the code quality has been 'programatically demonstrated' to be unsacceptable
> for inclusion. Prove to use that including this code would make Wine worse!

Code quality does not get programmatically demonstrated. 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.

> > Please don't be inconsistent. Is it a matter of distros or "regular desktop
> > users"?
> 
> Of course it is a matter of desktop users of desktop distributions! Have you
> forgotten what Wine is actually for??? Running desktop applications ringing a
> bell?

Wine was originally intended as a tool for porting win32 apps to unix-likes.
Should we abandon libwine apps just because most people use Wine to run native
win32 apps?

> ( I do appologise in advance for feeding the troll )

I am only voicing arguments that, afaik, are the current state of affairs since
the last pulse discussion on wine-devel. I'd personally like to see progress in
supporting pulse, as long as it's done in the right way. It might not be very
clear what the right way is (winealsa/wineoss/winesd improvements, which would
probably involve abstracting the common driver code into a separate module, or
separate winepulse driver), but what is clear is that the current patch does
not meet the required standards. I don't set those standards.

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