http://bugs.winehq.org/show_bug.cgi?id=10495
--- Comment #217 from Ben Klein shacklein@gmail.com 2010-02-13 17:16:38 --- (In reply to comment #216)
(In reply to comment #215)
winealsa has already been improved to work better with pulse.
No, that was tried, but it still doesn't work any better than it did before. (stutter, dropout, latencies)
This does not correlate with my experiences doing user support in #winehq. There was certainly marked improvement.
ALSA's OSS emulation doesn't have OSS4 features, and does not work with dmix, so software mixing while using ALSA's OSS is impossible.
You are confusing the kernel version of OSS emulation with alsa-oss - the whole point of the latter is that it works with dmix.
No, I'm not. And alsa-oss is unstable enough to warrant an independent winealsa driver.
What more can a pulseaudio proponent wish for?
A bit more of help & goodwill would be nice. Oh, and of course no "us against them"-labeling people "proponent". That would be great, too.
The ball is not currently in my court.
As soon as someone demonstrates the technical reasons why a separate winepulse is needed (and why you can't do the same things with an improved winealsa) [...]
Let's try it with a fun fact first: winealsa tried for over two years now - and didn't manage.
No. There have not been two years worth of attempts at getting winealsa to work better with pulse. The pulse-related patches to winealsa have gone in much more recently.
Now, here's the technical reason: A native sink is better than a compatibility sink.
I would thank you not to put words in my mouth, and do not attempt to turn this thread into a technical discussion on the merits (or lack of) of pulseaudio.
The only thing that is certain is that winealsa (or wineesd) doesn't work _right now_ and winepulse does.
This is not a certainty. From what I gather, it's app-dependent. And I'm still waiting on an answer to how MIDI is handled.