http://bugs.winehq.org/show_bug.cgi?id=10495
--- Comment #139 from Immanuel elmano@gmx.at 2009-09-27 00:53:48 --- (In reply to comment #138)
[...]to not use pulse (e.g. pasuspender) or tric pulse into likeing Wine (e.g. padsp, which only works for some people).
sry, but imo pasuspender/padsp are non-solutions as for me they break more than they fix.
Then use a system that works properly and doesn't hate Wine like ALSA's built-in dmix. Or don't use Wine with audio.
that's also a non-solution
So you're saying Wine can never provide a satisfactory pulse driver because of limitations of pulse? On this point, we are agreed.
nope, he said that wine sometimes does some nasty stuff in its alsa-driver and thus can't be expected to work 100%.
There is as of yet no demonstration that the ALSA driver cannot be reduced to the "pulse-safe" subset without compromising features or performance. I suspect this is the case, but if you have read the discussion, Wine's core developers require a definite and demonstrated (by code) NEED for a separate pulse driver before it will be considered for upstream.
I can give them a demo-system with non-working alsa-driver (as it kills other audio streams) and working pulse-driver. if that's not enough I may say I'm a little annoyed by that policy.
Enthusiastic developers have been known to disappear completely. "Someone is willing to maintain it" certainly goes in favour of the pulse driver, but does not satisfy the remaining objections.
jeah, and maybe he gets hit by a car next week, who knows. and maybe all the devs have the same faith and we should cancel the project alltogether -.- No, seriously: it could work the same way it does in the kernel where drivers with no maintainer get flagged and removed in subsequent releases.
just m2c