(In reply to comment #110)
> Pulseaudio provides what is desired by users, so a suggestion to just disable
> it to run Wine is likely to be greeted just like a suggestion to just disable X
> and run Wine in a framebuffer.

I don't follow the logic, unless you can provide a working X11 emulator for framebuffer that provides hardware accelerated OpenGL. It'd be more like if XCB wasn't written to be fully backwards compatible with libx11, and the developers of XCB saying "fix your broken X11 apps so they'll work with our shiny new XCB".
 
> > So fix it. Write a per-stream volume control plugin for ALSA/dmix or JACK.
> 
> That is not possible - an ALSA device changing the amount of mixers it has at
> runtime will break all kinds of funny things. And why should I write a
> completely new sound driver in the kernel or a subsystem in Jack just because
> you don't want to accept a new feature or a subsystem in Wine?

libasound is userspace, not kernel.

> > > JACK is only needed for sound editing, where you must have guaranteed real-time
> > > latency (which Wine does not provide anyway)
> > 
> > Wine's support for latency is not the real issue here, nor are you correct
> > about JACK *only* being needed for sound editing, but that's all off-topic
> > here.
> 
> And yet you bring up latency as the reason why adding PulseAudio to the stack
> is unacceptable and do not provide an example of widespread Jack use outside
> audio editing circles.

1) JACK is completely off-topic for this bug.
2) "not the real issue" for JACK. JACK needs real-time kernel support for real low-latency stuff. Same as Pulse in this way.
3) I did not bring up latency; I was responding to someone else who did.

> > > and it is possible that FPS
> > > players could benefit by disabling PA and using ALSA directly to gain a few
> > > miliseconds in audio latency. However for the rest of Wine users PulseAudio is
> > > the ultimate option in usability.
> > 
> > Not when it doesn't work.
> 
> PulseAudio works just fine.

No it doesn't. If it did, we wouldn't need a discussion on the best way to improve Pulseaudio support in Wine.

> It has far less bugs than ESD had when driver for
> it was introduced into Wine.

Difference is that ESD and Arts daemons did not provide an ALSA compatibility layer. Pulseaudio does, but it doesn't suit Wine's current needs.
 
> > And "a few milliseconds" is much more significant
> > than you may think, especially when it's adding to already existing latency
> > issues (which is the current problem with winealsa and plug pulse).
> 
> And if that is so, then no pro-gamer would choose Wine anyway, so why cater to
> them?

Who said anything about GAMING? Wine is not just used by gamers, nor is Linux. Even so, Wine's goal is to cater to *everyone*. Low-latency is required for professionals, but it doesn't matter for regular users. So you're suggesting Wine should explicitly say "we don't want professionals, only casual users" by saying latency is not an issue.
 
> > Regardless, you're not adding much (if anything) to this discussion ... Which
> > option are you voting for, the "winepulse driver" option or the "fix winealsa"
> > option?
> 
> I *advocate* that both bugs - the wishlist bug of a new driver for pulse and a
> bug that wine uses nonsafe ALSA API should be fixed.

This is no longer a considered a "wishlist for driver" bug; it is considered to be for improvement of winealsa to talk to Pulse better. Once there has been progress there (and ONLY then), it can be determined whether a Pulse driver is *really* required.
 
> With the way Ubuntu and Fedora are pushing for PulseAudio, I would not be
> surprised if the respective maintainers would pick this patch up and apply it
> in these distributions, regardless of your personal opinion on the matter. It
> would be better if such features were included and cleaned up upstream,
> however.

These patches are not supported by WineHQ in any way. If Ubuntu and Fedora package maintainers do so, then it is their responsibility to manage any bugs or technical support relating to Pulse and Wine. Users with prepackaged winepulse drivers that post on the WineHQ forum, users mailing list or IRC channel will be inevitably turned away and sent to the relevant distro-specific forum.