http://bugs.winehq.org/show_bug.cgi?id=10495
--- Comment #183 from Ben Klein shacklein@gmail.com 2009-10-10 05:52:44 --- (In reply to comment #182)
(In reply to comment #181)
Because they didn't have to rewrite all their apps to support pulse; pulse has esd compatibility.
Just they did rewrite all the apps and dropped any reference to ESD completely in 2.28. It's gone from GNOME.
No, it's not a *dependency*. You can still get sound in GNOME without pulse running.
Sure, I'm certain there are patches floating around to do that by hand.
No. Vanilla GNOME supports ALSA audio backend.
Changing something just because some - but not all - distros changed it is not a good reason to accept code into Wine.
Let's replace "some" by "most" makes it a good reason, tough.
No it doesn't.
Because adding drivers now means more work - potentially a lot more work - later on.
No. A complete rewrite later only depends on what systems it will target.
All systems, by definition.
It looks like no new audio drivers will be accepted until those internal API issues are resolved (basically, no more code duplication), thus the suggestion for an audio redesign bug to block the pulse support bug.
Which doesn't make any sense at all, as API design has nothing to do with code.
API design has *everything* to do with code, because the code implements the API design.
It also cuts out people using systems, e.g. Solaris, where ESD is still more common than pulse.
You are aware that Linux running PulseAudio is a lot more common than OpenSolaris running EsounD?
You are aware that Wine cannot just support what is "common" or popular?
If wineesd was in better condition, we could actually drop winepulse in favour of wineesd.
Sure, because writing code the dead ESD system seems the perfect way to go.
Don't knock it till you've tried it. It *would* work just as well as a native pulse driver. As it is, wineesd doesn't even work well with ESD.
(In reply to comment #180) Then again, it's probably easier to ignore this problem, hope that it goes away and screw over most Linux users. That has the additional benefit of doing the same when either PulseAudio or Boomer hit OpenSolaris, right?
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.