I have read several problems for a long time about wine and pulseaudio in Ubuntu but never understood it clearly. What are the problems or seem to be the problems related to wine and the use by default of pulseaudio in regards to sound in games executed via wine. This affects a whole range of users that use Ubuntu but want to still be able to play specific windows games.
Wine has to provide a sound access layer for Windows applications, much the same way that Windows would. But Wine, unlike Windows, lives on top of an audio stack. Almost all the hardware control is abstracted away. Wine has to know how to talk to the stack so the right sounds are made.
While you'd have to really search for a problem-application today, what you're describing was years ago.
Once upon a time...
Historically Wine has liked OSS and ALSA. They provide predictable interfaces but they aren't easy to code to. It took ages for the ALSA support to a just works stage.
If you want a stack diagram, it's very simple: Hardware → ALSA → Application
It was a simple stack that did, just about work, albeit with many locking issues (one application playing something, everything else gets muted, etc).
Then PulseAudio got popular.
Suddenly Wine didn't have access to ALSA because PulseAudio was locking the device. Instead Wine had to route all its audio through an ALSA-device-emulator that PulseAudio provides for applications that aren't willing to speak "PulseAudio".
So in the case of an application that only knows ALSA or OSS, your audio stack now looks like this: Hardware → ALSA → PulseAudio → PulseAudio ALSA emulator → Application
Unfortunately the PulseAudio-ALSA-emulation-layer wasn't great. It would support a couple of channels and a few recording options but nowhere near as much as the ALSA that it sat on top of.
The perceived problem was always "the other guys' fault"
Wine audio now didn't work. With hindsight it's easy to see where the problem really was but there were three opinions at the time that made Wine a real battleground:
And to the present day. Things seem much better, so what happened?
Well everybody gave a little.
And while it might seem like it, that's not the end of this story. I think the eventual aim is to remove the WineALSA driver and interface with something like OpenAL or GStreamer. I'm not sure how those plans have evolved since MMDevAPI came in but that should allow Wine to remove all but the smallest amount of interfacing code.