[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10495


Alexey Loukianov <mooroon2 at mail.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mooroon2 at mail.ru




--- Comment #228 from Alexey Loukianov <mooroon2 at mail.ru>  2010-02-15 19:22:30 ---
(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)?

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.