Comment 244 for bug 371897

(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