(In reply to comment #172)
> Because the current architecture doesn't scale that well.
Obviously, right now it scales well enough to allow a working driver for PulseAudio. ;)
(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.
> Like someone else pointed out earlier, stop-gap solutions are usually hacks,
> and when a hack is in place, people are rarely tempted to fix it properly.
Those people also tend to point out that there will be a complete rewrite of the Wine sound layer and all the drivers need to be rewritten anyway - so that proper fix will happen anyway.
> If you'd like a stop-gap solution, compile wine yourself with winepulse's driver.
Sure _I_ can. Can those people switching straight from Windows?
(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.
> Wine does not target specific distros.
True - Wine targets users switching from Windows to other systems, allowing them to run their programs and games. Those users tend to switch to a specific _kind_ of distros... and those being mostly the popular desktop ones.
So while Wine might not target _specific_ distros, it indirectly targets a _kind_ of distros.
> The problem is that winepulse is not even a "good" solution - if the whole
> internal sound API gets rewritten to be more modular, then it's even more work
> to port a new driver over to it.
If it's a complete rewrite anyway, where's the problem getting a working driver now for the old system?
> 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.
(In reply to comment #178)
> It is an objection to the idea of dropping winealsa for winepulse.
(In reply to comment #172)
> Because the current architecture doesn't scale that well.
Obviously, right now it scales well enough to allow a working driver for PulseAudio. ;)
(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.
> Like someone else pointed out earlier, stop-gap solutions are usually hacks,
> and when a hack is in place, people are rarely tempted to fix it properly.
Those people also tend to point out that there will be a complete rewrite of the Wine sound layer and all the drivers need to be rewritten anyway - so that proper fix will happen anyway.
> If you'd like a stop-gap solution, compile wine yourself with winepulse's driver.
Sure _I_ can. Can those people switching straight from Windows?
(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.
> Wine does not target specific distros.
True - Wine targets users switching from Windows to other systems, allowing them to run their programs and games. Those users tend to switch to a specific _kind_ of distros... and those being mostly the popular desktop ones.
So while Wine might not target _specific_ distros, it indirectly targets a _kind_ of distros.
> The problem is that winepulse is not even a "good" solution - if the whole
> internal sound API gets rewritten to be more modular, then it's even more work
> to port a new driver over to it.
If it's a complete rewrite anyway, where's the problem getting a working driver now for the old system?
> 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.
(In reply to comment #178)
> It is an objection to the idea of dropping winealsa for winepulse.
Good. Drop wineesd for winepulse, problem solved.