Comment 401 for bug 371897

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