Comment 334 for bug 371897

(In reply to comment #228)
> winealsa:
> [App]->[Wine]->[Pulse compatibility layer for ALSA]->[Pulse]->[Sound Backend,
> most probably ALSA or OSS kernel driver]
>
> wineopenal:
> 1st variant: [App]->[Wine]->[OpenAL-soft]->[OpenAL PulseAudio
> backend]->[Pulse]->[SB]
> 2nd variant: [App]->[Wine]->[OpenAL-soft]->[OpenAL ALSA backend]->[Pulse ALSA
> compat]->[Pulse]->[SB]
>
> winepulse:
> [App]->[Wine]->[Pulse]->[SB]
>
> IMHO, it is obvious that the winepulse path is the shortest one with the least
> overhead.

Invalid argument.

winealsa:
[App]->[Wine]->[SB]

wineoss:
[App]->[Wine]->[SB]

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

> User will be either forced to reconfigure his/her system to utilize
> the ALSA/dmix

... which takes next-to-no effort.

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

> Telling that it might be perfectly possible to rewrite winealsa driver to work
> well in conjunction with PulseAudio seems to me as a nonsense: even in case it
> is possible (it must be proven separately because it is not an evident fact) it
> 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.

> that means that in such case 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.

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

> So, please stop lying to people that winepulse is not required.

Please don't try to start another flamewar.

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

> Why not to change the wine in a way that
> it would be easily possible to compile and add sound subdrivers to the existing
> wine installation?

This has been discussed as a possibility to improve existing sound drivers (making them more maintainable) as well as adding new drivers (winepulse or wineopenal). If this happens, then a new winepulse driver may be examined more 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.