Comment 338 for bug 371897

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