© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
(In reply to comment #179)
> (In reply to comment #173)
> > Wine supports more than just Linux...Esound is the easiest way to get sound
> > working on OpenSolaris, and perhaps others.
>
> And GNOME just dropped EsounD in favor of PulseAudio.
Because they didn't have to rewrite all their apps to support pulse; pulse has esd compatibility.
> (In reply to comment #174)
> > ALSA isn't going away, not even on "small" distros like Debian and Gentoo.
>
> As pointed out above, PulseAudio is a GNOME dependecy now, so even those will
> ship with it sooner than later.
No, it's not a *dependency*. You can still get sound in GNOME without pulse running.
> > Wine does not target specific distros.
>
> So while Wine might not target _specific_ distros, it indirectly targets a
> _kind_ of distros.
"Indirectly" being the key word here. Wine does not target specific distros, nor does it (explicitly) target specific types of distros. Changing something just because some - but not all - distros changed it is not a good reason to accept code into Wine.
> If it's a complete rewrite anyway, where's the problem getting a working driver
> now for the old system?
Because adding drivers now means more work - potentially a lot more work - later on.
> > Maybe we should have a separate bug for redesigning Wine's audio API, and set
> > it up as a blocker to this one?
>
> Why? It works right now - a total redesign is a completely different matter.
You just answered your own question. A total redesign IS a completely different matter, so I suggested a separate bug. 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.
> (In reply to comment #178)
> > It is an objection to the idea of dropping winealsa for winepulse.
>
> Good. Drop wineesd for winepulse, problem solved.
No, because the underlying issue of Wine's internal sound API is not solved. It also cuts out people using systems, e.g. Solaris, where ESD is still more common than pulse.
If wineesd was in better condition, we could actually drop winepulse in favour of wineesd.