(In reply to comment #220)
> Please stop this. Every discussion about Pulseaudio is useless. Please read
> this: ... description of the wonderful feature with OpenAL follows...
> 
> So please stop spamming about whether or not wine should support a pulseaudio
> driver, because there there is absolutely no point in this. Someone is already
> working on a solution that is far superior to anything you'd come up with in
> this bug report. 

That is not true for the obvious reasons even a non-programmer can understand.
Here are some "pictures" of the path that the audio data have to travel on a PulseAudio-enabled system when using different Wine subdrivers:

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. 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. User will be either forced to reconfigure his/her system to utilize the ALSA/dmix instead of PulseAudio or to get by with a non-fully-functional sound subsystem.

Me personally don't like the PulseAudio at all as it seems to do more harm to the my style of using soundcard than the advantages it promises to give (but sometimes fails). But that is just because I use semi-pro soundcard in conjunction with the Jack and -rt kernel to complete the tasks I need in Ardour and a like. But when it comes to an ordinary "home use" of a modern linux distro like Ubintu/Mint or Fedora it seems to me that PulseAudio had established quite well nowdays to be usable by non-professional users.

And IMO it is a good reason for Wine to support PulseAudio natively.
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. And 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. Less possible ways means that there will be less tricks available for use to optimizations. And that means that winealsa driver that is capable of seamless 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.

This is exact the reason why the native PulseAudio support is requred for Wine. Having two separate drivers for two separate sound subsystems with each one optimized to its best for the sound subsystem it is targeted to is obviously better than having one general-purpose drives that 'fits all at once' but is by its nature less optimized and provide less functions than the target-specific driver may provide.

So, please stop lying to people that winepulse is not required. It certainly is for the systems where the majority of applications are configured to use PulseAudio as their sound backend. winepulse will offer shorter sound path and better integration with the target sound subsystem than winealso can offer. The 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.

Thanks to Art Taylor, winepulse is available to the users that need it and it is maintained well-enough for general use. And I don't think that the inclusion of the patch to the Wine is required. 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? I mean, why not to do it in a way the same way the compilation of the linux kernel modules may be done (using only kernel-headers instead full kernel source tree + patch)?