[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

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

--- Comment #296 from Ben Klein <shacklein at gmail.com> 2011-01-08 19:49:29 CST ---
(In reply to comment #289)
> Just a quick note - the ALSA driver is buggy again. It had worked good for some
> time, but no it again is stuttering and stops working after approximately 10
> minutes. We really need pulse drivers in.

This is not the place to complain that winealsa is buggy. If it hasn't already
been reported, report a new bug.

(In reply to comment #291)
> Ben Klein: Please stop sputtering nonsense like that. The simple fact is that
> most Linux end-users are now using PulseAudio, and Wine doesn't work properly
> with it at all.

Like it or not, this is NOT a valid reason for including winepulse. The audio
subsystem in Wine is being restructured to cut down on copied code and
maintenance issues with the existing drivers. Once that has been accomplished,
new audio drivers can (at least in theory) be trivially included.

(In reply to comment #294)
> The main problem I see here is that some of the people still see pulseaudio as
> a sound *mixer*, while that stopped being its main focus awhile ago.
> Now, its main job is being audio stream manager and that's why removing it is
> quite crippling in some of the cases.

Pulse being a "stream manager" is also the reason why using it with Wine is
generally "crippling". Wine is not designed to cope with the sorts of things
pulse does (namely, it expects lower latency and more control), and pulse is
not designed to copy with the sorts of things Wine wants to do.

> P.S. Ben, yes it is *much* better and more user friendly to use approriate
> GNOME and KDE interfaces as appropriate instead of inventing your own low level
> things on X.

There is an argument that it is more user-friendly, but only if GTK, QT and KDE
are equally supported. However, it is most certainly NOT appropriate for Wine
to use GNOME/GTK, KDE or QT over the current X11 implementation. Wine needs to
be able to control specific positions and behaviours of controls, and report
back to win32 apps, in ways that GTK/QT etc. cannot be configured for
trivially. If you have ever tried to design a win32 GUI, you would understand
this. Wine devs would need to create their own widgets for GTK/QT/whatever
system is switched to; so why not do that with X11 directly?

> The best free software projects (Firefox, OOO, ...) integrate with
> Gnome and KDE and use, for example their Print dialogs, file open/save dialogs,
> colors and icons, ... That is the best practise among free software. Wine is an
> archaic relic from 1990s in this regard, unfortunately.

There is arguably work to be done in desktop integration, but using a
second-order graphics/widgets library is NOT the way to go about it.

(In reply to comment #291)
> There's no need to defend this sorry state of things either,

Yes there is, as the current sorry state is being attacked by people who don't
care that, as you say:
> the Wine
> developers themselves are working (slowly) to obsolete the current situation
> with a new audio back-end.


> In the meantime, WinePulse is the currently-available solution that offers a
> superior end-user experience.

Tough. It cannot be included in Wine as the audio subsystem is going through an
overhaul. As a result, it cannot be supported by WineHQ in any official way.

> Stefan: Actually it would be better to move away from X11 to something
> cross-platform like SDL or Qt, as the X11 dependency causes all sorts of silly
> problems on Mac.

This is simply not feasible. I've already discussed why QT cannot be used; SDL
is similar but worse as all widgets have to be implemented from scratch. Not to
mention (potential) issues with resource usage, multiple windows, window
resizing, various latencies ...

(In reply to comment #293)
> (In reply to comment #292)
> > First of all, both sides should stop *pure* trolling,
> > cause that's just what that theming "discussion" is (at least in this bug).

My argument was simply an analogy to show that "everyone is doing it" is NOT a
valid argument, especially when technical considerations are concerned.

> From an outside observer's view who doesn't care one way or the other, it would
> seem like ben klein is the troll. It doesn't really matter to me whether this
> longstanding bug is fixed or not, but spouting off stuff like alsa is more
> prevalent than pulseaudio as fact and then not backing it up with any sources
> is trolling plain and simple.

You want sources? kernel.org has them. Pulseaudio does not provide kernel audio
drivers, nor does it interface directly with those drivers (by userspace libs).
It must therefore use a backend, and on Linux systems ALSA is by far the
dominant backend (driver and libasound/alsalib/whatever included). The only
other serious contender for audio backend on Linux is OSS4, but that cannot be
included in kernel upstream for licensing issues. And as pulse is OPTIONAL
software (just as Wine, Xorg, GNU tools etc. are) and is not installed on EVERY
Linux system, ALSA is irrefutably more common than Pulseaudio.

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