Comment 336 for bug 371897

> Invalid argument.
>
> winealsa:
> [App]->[Wine]->[SB]
>
> wineoss:
> [App]->[Wine]->[SB]
>

You are either trolling or wrong.
Sound paths you specify are for "pure ALSA" system, not for the "PulseAudio-enabled" system.

> > Without any doubts in case we turn off the PulseAudio completely the
> > path will be even shorter, but it will hardly break the sound-related
> > applications on a system that was tuned to use PulseAudio as it's primary sound
> > backend.
>
> pulse is not a backend. Your own diagrams invalidate your point.
>

Pulse is a backend. Prove that is it not. And - to be correct - provide your definition of a term "backend", please, as I suppose we're talking about a different things when use a word "backend".

> > User will be either forced to reconfigure his/her system to utilize
> > the ALSA/dmix
> ... which takes next-to-no effort.

... in case it is pure-ALSA system without PulseAudio. Have you ever used an PulseAudio-enabled system where ALSA hw-devices are often locked by PulseAudio making dmix break (that is one of the reasons I don't use PulseAudio on my "linux sound processing workstation")?

> > instead of PulseAudio or to get by with a non-fully-functional
> > sound subsystem.
> ... except it's not fully-functional, and OpenAL would actually help that.

OpenAL is a good thing to implement driver for, but unfortunately it is nothing more than another software sound library nowdays when it comes to linux world. Native hardware-accelerated OpenAL drivers are there for Windows and MacOS X, but there are nothing of this kind for Linux. Actually, I hadn't heard about any contributions to the Linux port of OpenAL from the Creative, and it looks like very unlikely for us to get native linux OpenAL-enabled sound drivers directly from major sound cards vendor :-(.

> > will limit winealsa driver to a some subset of the API that libalsa offers.
> 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"? Nevertheless - I repeat it again - a general-purpose "one-fits-all" driver will always be more generic than specialized ones, and it will not include target-specific optimizations in it (unless some additional execution branches will be introduced in it, i.e. a sort of subdrivers - and that is not far from implementing a separate target-specific driver).

> > ... winealsa driver will loose some possible ways it might behave if
> > it were targeted to a normal (non-pulse-emulated) ALSA devices.
> Yes, but what hasn't been proven is that Wine actually *needs* to do those
> things.

Surely not. The opposite hadn't been proven as well.

> > usage of PulseAudio-emulated ALSA devices can not be optimized to the same
> > extent as it is possible for the non-compatible-with-Pulse winealsa.
> That is equally true of winepulse.

Equally true... for what? winepulse has nothing to do with ALSA, it should use native PulseAudio API and it should be optimized for this. winealsa should use libalsa native API and should be optimized for that. That are the obvious facts.

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

> > only _real_ reason I can see why not to include the winepulse in the generic
> > wine source are the maintenance problems. All the other reasons that were
> > stated in the comments upwards seems to be more a political one.
>
> Code quality may be political, but it made Wine what it is today. Without code
> quality, Wine would be a dying project like Cedega or ReactOS.
>

The quality of a code is a subjective thing. I've been working some time as a programmer supporting legacy code and reviewing proposed patches to make it better. There always were some things that we were not agreeing at with colleagues while the proposed code was working in general. Then again - as I had already said - IMHO there's no need in accepting winepulse in mainline wine source tree. It is sufficient just to make it easier to build it separately from the wine.

> seriously as a long-term solution. The reason why it hasn't been done is that
> it's a *lot* of work to do so, and so far no one is willing to do it.

Got it. I hadn't had a lot of free time to look at the wine sound drivers sources and I was thinking that it wouldn't require a lot of changes to wine. If it really requires a lot of changes then it makes clear why it hadn't been done so far :-(.