Comment 316 for bug 371897

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