Comment 462 for bug 371897

(In reply to comment #341)
> I am (unluckly) well aware how buggy PA is. Point is, just look at the comments
> of this bug report. Look at the answers we've been given ...
> ...
> Really, I appreciate the dev's work on such a big and complicated project as
> Wine is, but some news about this old (yet persistent) issue could help
>

Sorry for delaying my answer for such a long time, but I have been having some medical issues last months preventing me from using computers.

Fact is that I'm not a Wine developer, so I can't provide you with an "official position on point". Still, I've been monitoring Wine's Bugzilla and wine-development list for a pretty long period of time so I can share with you my conclusions on the topic I had made through observations. Here they are:

a) We all know a sad fact that not all people officially working on bugzilla maintenance are always polite and unbiased. On the contrary, most of the times you should expect a bit of rudeness and/or tension trying to get your bug not "CLOSED WONTFIX", a patch accepted into the Wine tree, e.t.c. Personally I don't like this much but it is the way it is and it works more or less, keeping in mind the amount of bug reports devs get posted with every day.

b) Audio subsystem rewrite we've been originally told about had been done, but not in the way it had been originally thought of. AFAIRK, initial intent was to get rid of all the old drivers, implement the only one instead, thus decreasing the maintenance burden from having to support N drivers into having to support 1 driver. It had been thought that OpenAL would serve as a viable backend, but in the end it turned out not to be a case. Instead Wine's audio subsystem had been rewriten so sound render path went through mmdevapi interface, and there had been three mmdevapi driver backends implemented for it: ALSA, OSS and CoreAudio. As far as I had read on bugzilla, mmdevapi maintainers are not against having separate PA mmdev driver in general, but as their time is limited they want to fix most of the outstanding show-stopper bugs in existing mmdevapi drivers first, and only then considering something like separate PA mmdevapi driver.

c) So, taking into account what I had written in (b) - current short term support policy for PA seems to be "Wine should work decently enough with alsa-pulse plugin, in case you have fresh-enough version of libalsa, alsa-plugins and PA installed", and possible long-term policy might include something like separate PA driver which would provide some additional benefits when used over ALSA->alsa-pulse render patch.

> Honestly, I can handle random crashes, loss of data, occasional lag, graphical
> issues (I remember the old times when most games wouldn't even start with
> Wine), but they all get fixed sooner or later... This issue, on the other hand,
> has been carried around for quite a while..

Well, it's not an "in-fixable" issue, actually. With older Wine versions you may wish to stick with out-of-tree patch that adds PA driver to the now obsolete winmm drivers architecture. If you want to use latest-n-greatest Wine releases (1.4+) - be sure to also use latest-n-greatest PA and alsa-plugins releases, it would fix most of the PA vs. Wine problems for you.

You know, Wine devs are not magicians. Audio subsystem rewrite is a huge thing and it had mostly been done by three people out there (Andrew, Joerg, Maarten, maybe someone else I had forgot about), so it's not a big surprise it took a big amount of time, especially knowing the tight requirements AJ puts on the code that is accepted for inclusion. Dev's done a great job, sound subsystem works almost perfectly nowdays, and it is even capable of intelligently workaround some of the bugs of alsa-plugins that had been there for years. Looking at the quality curve Wine's audio subsystem had been gaining recently - I won't be surprised if some time later this year (say, this summer) there won't be any problems with using Wine vs. PA.