http://bugs.winehq.org/show_bug.cgi?id=10495
--- Comment #229 from Ben Klein shacklein@gmail.com 2010-02-15 20:17:46 --- (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.