http://bugs.winehq.org/show_bug.cgi?id=10495
--- Comment #153 from Ben Klein shacklein@gmail.com 2009-10-07 19:10:18 --- (In reply to comment #152)
(In reply to comment #151)
Arguing the merits of PulseAudio is periphery. Some people use it, some people also use wine. You cannot "fix" people into not trying to use them together. That said...
Equally cannot "fix" people trying to use Wine on Windows natively.
Except when using Wine, Skype etc. Hence the issue. And given that dmix does not suffer from these same latency issues, it's obviously a problem with pulse. Face it, pulse is virtually broken by design
Substantiate? Dynamic latency management is probably one of pulse's most wonderful features. Is it for a professional, static, audio situation? No. Is it for real-life, dynamic audio situation? Yes. 50ms total latency is common.
50ms latency from pulse is only achievable with the -rt branch kernel. For everything else, dmix does not suffer from such serious latency issues (especially in Wine, Skype etc).
Or hardware-accelerated ALSA, which is disabled by pulse.
Most audio hardware has no hardware accelerated mixing, which makes it difficult to implement hardware-accelerated mixing.
*Professional* audio users, those addressed by the comment, are most likely to use cards that have hardware mixing in hardware and drivers.
There have been specific objections to the proposed winepulse *code* (not just the concept) before and I as far as I know the few people who have worked on it are no longer attempting to get it accepted upstream. Patches have to be sent to wine-patches mailing list for review.
That was a /long/ time ago. I've stopped trying to get it accepted in vanilla wine because arguing the concept to people with prejudgments seems barrier enough.
If you've stopped trying to get Wine upstream to support pulse, this whole discussion is moot. So much for the "developer willing to maintain" argument.
IMO the audio aspects of wine should be redesigned (nobody's fault, things evolve over time.) However, such an undertaking is a lot of work.
Then someone needs to start working on it. I believe you just volunteered, Art :P
If wine's implementation of the (depreciated) MME was consolidated from per-driver to one location and then a common audio interface abstraction for MME was written, I would lobby for the inclusion of pulse as a target backend into official wine.
Assuming this is even possible. Even just a Proof of Concept would be helpful here.