Comment 266 for bug 371897

(In reply to comment #160)
> But part of the problem is that pulse is marketed as a general solution to all
> audio problems. They claim it has low latency etc., which fuels calls for it to
> replace every other audio API. However, on closer inspection, it's unsuited to
> anything more than the most basic usage.
the only difference being that it works quite well for my needs (in contrast to some "advanced" solutions) and offers some nifty features.

> 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.
So, to rephrase this: right now we have a working solution (winepulse) and one that "we may get compatible some day" (winealsa) and you are telling us is that "all we have to do" is to _prove_ that winealsa "can't be made pulse-friendly"? what kind of logic is that?
> The suggestion of redesigning wine's audio subsystem,
> although time-consuming and resource heavy, is the first stepping stone in this
> direction.
woohoo, maybe we get pulse-support in 2012 -.-