Comment 288 for bug 371897

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