Comment 289 for bug 371897

(In reply to comment #183)
> You are aware that Wine cannot just support what is "common" or popular?

I think I'm used to be aware that the use case for Wine is exactly to support what's "common" and popular - that's the whole point of supporting Windows applications under different OS', isn't it?

> API design has *everything* to do with code, because the code implements the
> API design.

That way around, sure - sorry for being unclear. Just old code, that is simply scrapped when the API redesign comes, should in no way influence either the API design or the new code written from scratch.

> It *would* work just as well as a native pulse driver. As it is, wineesd doesn't even work well with ESD.

Hey, if you can fix wineesd for _now_ to allow, say, playing Diablo 2 without action samples playing about a second after the action - go for it.

> Or, on the other hand, we could overhaul the internal audio API and make it a
> lot easier to maintain new and existing drivers, thus paving the way for
> winepulse/wineboomer/winespeedaudio/wineopenal whatever inclusion upstream.

Nobody is asking you to stop that, on the contrary.

The only thing people are asking is to get a driver in vanilla Wine that allows them to use Wine well with current desktop distros until that golden age of new Wine Audio dawns.

On the other hand, I'm tired of reading the same excuses to artificially create deadlocks over and over again: Postponing everthing to the shiny new code that will miraculosly fix everything (but didn't even start for about two years now) is just as frustrating as claiming the need to drop drivers when including new ones, then later on locking down on that with the point that people still need it, even if other whonder why those are still there.
Don't bother repeating those - I won't bother you repeating myself anymore, don't worry Austin.

PS: I'm well aware that there are coding style issues with the patches.