© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
(In reply to comment #162)
> (In reply to comment #158)
> Again another great contributione to the flameware. Do you have any idea what
> Stefan was writing about? Maybe you should read his comment again.
So you argue that Linux users be forced to either use an inferior OSS or install pulseaudio and live with it if they happen to want sound in Wine?
The main argument for supporting pulse *at all* is that people use it. People still use plain ALSA, and with good cause. It's hypocritical to drop winealsa in favour of winepulse *unless* some other driver takes over the job of winealsa and provides native ALSA support.
> > The point remains that winepulse will only be accepted if a definite,
> > demonstrated need is presented - i.e. that winealsa (and other drivers) can't
> > be made pulse-friendly.
> I don't know the Wine set-up in detail but AFAIK it is not your decision and
> I'm very glad about that.
>
> You simply don't know what Pulse is good for and cultivate your prejudice.
Obviously you have no interest in ending the flamewar. Your accusation, correct or not, of my contribution to the war is hypocritical.
> ALSA via Pulse does have a higher latency than a direct Pulse API. Thus you
> demand a "definite, demonstrated need" on one side but claim that latency is
> the highest priority on the other side.
In this case, latency and performance are not synonymous. Apparently, improvements have already been made to winealsa that make it pulse-friendlier. If those improvements continue enough, there is no need for winepulse.
It seems to me that pulse is used by people to whom latency isn't an issue as long as it is "good enough". If winealsa can be made equally "good enough" for pulse users, then it should be.