Comment 257 for bug 371897

(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...

> 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.

> 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.

> 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.

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. Meanwhile the wine-pulse code exists and works better for people who use pulseaudio to using an different audio api in parallel or emulated on top of pulseaudio.

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.