http://bugs.winehq.org/show_bug.cgi?id=10495
--- Comment #161 from Immanuel elmano@gmx.at 2009-10-09 01:51:59 --- (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 -.-