Comment 258 for bug 371897

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