[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

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





--- Comment #203 from Ben Klein <shacklein at gmail.com>  2010-02-12 19:05:20 ---
(In reply to comment #201)
> (In reply to comment #200)
> > dmix is a "better solution" because it works. pulseaudio has extra features,
> > but it's problems like this that make it unsuitable for the average user.
> 
> PulseAudio works as well perfectly fine for a wide range of users. It works
> perfectly fine with all the fine applications that support it. Naturally it
> does not work as good with Wine and that is exactly that this BUG is here. This
> bug in Wine of not supporting PulseAudio.

You could equally that it's pulse not supporting Wine, and that the bug is
pulse's issue. As it stands, there's a gaggle of alternatives to pulse, some of
which still around and in use today. And for the most part,
winealsa/wineoss/wineesd work OK with modern ine and pulse. The absolute need
for a separate winepulse has not been programatically demonstrated; the best
argument is that "everybody (or a lot of people) use it".

> > > Fedora, Ubuntu, Mandriva, Linux Mint, and openSUSE at this point. I believe
> > > that easily makes it a majority by any count. And it has been here for nearly 2
> > > years.
> > 
> > That's nowhere near the majority. distrowatch.com has plenty more.
> 
> Please don't be silly.

Please don't be inconsistent. Is it a matter of distros or "regular desktop
users"?

> 2) I've done the research before: over 90% of all Linux distros
> are derivative distros from either Debian/Ubuntu or Fedora. With over 60%
> falling in Debian/Ubuntu camp. And those have pulseaudio.

You can't bundle Debian in with Ubuntu. Debian does not install, nor recommend,
pulseaudio by default.

(In reply to comment #202)
> All, it is not useful to debate the topic of "whether pulseaudio?" or "what is
> the best audio subsystem?" Those are not the topic of this bug report. Please
> refrain. Whether native or through alsa-pulse is on topic.

I will continue to object to peoples demands that "Wine must support
pulseaudio" (or more specifically this particular patch set) based on the ad
populum fallacy. Seriously, there are better reasons for pulse to be supported
than this. I have no objection to pulseaudio being supported *correctly*.

> (In reply to comment #193)
> > (In reply to comment #191)
> > > Is it because:
> > > *) patch code is of bad quality
> > The patch does not meet AJ's quality standards, and no one seems to want to fix
> > this.
> As the original author, I am willing to fix this. Last attempt at a code review
> was not by AJ and was on an old version.

Please do. I suggest consulting wine-devel about what further work needs to be
done.

> > > *) patch doesn't conform coding standard
> > See above.
> More useful feedback is needed, but it's quite clean. Naming and indentation is
> consistent. I should revisit pulse.c on a rainy weekend though.

With "see above" here, I meant to refer to the more general quality standard
rejection. I'm sure your coding style is consistent and acceptable.

> > > *) patch is incomplete
> Supports WaveOut, WaveIn and Dsound playback and capture. All testsuite tests
> pass.

How do you support DirectMusic and other MIDI methods? (This is mostly for my
personal interests.)

> > > *) current wine devs/mantainers don't want to mantain this piece of code even
> > > if it's well written and works?
> > If it's well written and works, then there would be little objection to this as
> > required maintenance would be low. So far, no one has put their hand up to 1)
> > fix the code standard, 2) prove that winepulse is 100% necessary and 3)
> > maintain a fixed and proven version of the module long-term.
> I am hesitant to put my hand up again because it's still scorched.

I'm sorry to hear this. You've put a lot of work into wine-pulse that I'm sure
a lot of people are greatful for. I'm also sure that the reasons for your
patch's rejections were not personal.

> > (In reply to comment #192)
> > > In the end it comes down to wine developers don't like having so many audio
> > > backends in the tree, and so don't want another committed to it.

Come to think of it, something that came up on wine-devel a little while ago is
that it'd be ideal for the audio subsystem to be redesigned (possibly more in
the style of wined3d) to make maintenance of multiple audio drivers much
easier. Of course, no one is willing to put their hand up for this either, as
it's a LOT of work.

> > No. What it comes down to is no one has proven programatically that winealsa
> > can't be made to work with pulse's ALSA emulation.
> Well, it can be coaxed into working by modifying buffer settings, and does work
> to a minimum extent, but it's not exactly ideal.

That's as it stands now, if I understand you correctly. But is it possible to
modify winealsa so that it's still pure ALSA but works correctly with pulse's
ALSA emulation?

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