[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

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





--- Comment #233 from Ben Klein <shacklein at gmail.com>  2010-02-16 05:46:44 ---
(In reply to comment #231)
> Pulse is a backend. Prove that is it not.

pulse is a middleware that depends on some other functional backend to work.

> Native hardware-accelerated OpenAL drivers are there for Windows and MacOS X,
> but there are nothing of this kind for Linux.

Creative does supply OpenAL acceleration for a limited range of driver/card
combinations. However, pulse cannot be hardware accelerated either, so I fail
to see your point.

> > The question is, will doing this cause winealsa to break? So far, no one has
> > demonstrated this either way.
> 
> What do you mean by a "break"? Will the (possible) loss of performance be a
> "break"?

There is no evidence that a loss of performance will certainly occur. If
someone can explain in detail the reasons why Wine needs to use non-pulse-safe
ALSA API, then that would settle this aspect of discussion (though it belongs
on wine-devel, not here).

> > > So, please stop lying to people that winepulse is not required.
> > Please don't try to start another flamewar.
> 
> There's no need to start a new one - the older is still burning.

The only hope to progress is to end the flamewar.

> The quality of a code is a subjective thing.

AJ rules supreme.

(In reply to comment #232)
> PulseAudio isn't tied to an ALSA/OSS

... which is part of my concern about how MIDI/DirectMusic is handled by the
proposed winepulse driver.

> So a.t.m. openal on
> linux is totally a software solution that uses other sound systems as output
> backend

Pulse is the same, except that it's *always* software.

> > And in the future using OpenAL as the multi-platform standardized backend.
> 
> OpenAL is an offtopic really for this bug

... except that it was mentioned that wineopenal will all but replace the other
drivers (in particular, the semi-dead, poorly maintained ones like wineesd,
winearts and winejack), and there was a suggestion that winepulse will not be
needed if wineopenal is implemented.

The rest of this is not really on-topic though:
> The only advantage that OpenAL can give when
> using as a bridge between Wine and Pulse/ESD/any-other-sound-server is the
> 3d-sound support "out of the box". That is worth having really, though.

I'm not sure if Wine is aware of any multi-channel stuff at the moment, but
there are other advantages to OpenAL.
1) It's cross-platform, and works with a wide variety of sound backends
2) It's just a library and not not a sound daemon (and thus depends on the
backend supporting software or hardware mixing as appropriate). It doesn't in
itself need an external program to run.
3) It allows OpenAL apps in wine to have a direct passthrough to the
host-native OpenAL libraries. I believe this is already implemented in Wine.

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