What are the problems between PulseAudio and Wine

Question

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.

Answer 1

Latest update: Wine 1.7.55 adds proper PulseAudio support.

There isn't much of a problem at all these days.

What you're describing was years ago.

Applications under Wine only know how to talk to a Windows sound stack, so as with most of the other Windows subsystems, Wine provides this. The problem comes from our sound stack changing significantly in the last decade.

Once upon a time...

... we only had OSS and ALSA. They provide predictable interfaces but they aren't easy to code to. It took Wine ages to get to a "just works" point with their ALSA support. The stack diagram was quite simple:

Hardware → ALSA → Wine/Win32-api → Windows app

The main problem with ALSA is it's notoriously finicky if you want more than one thing to play at once. Applications could accidentally lock it from others.

Then PulseAudio got popular.

Suddenly every desktop had this thing called PulseAudio. It was another layer between applications and ALSA to allow for many applications to make noise at once and add features like sound-over-network.

But Wine still only knew how to talk to ALSA, and there was now this PulseAudio thing hogging it right from boot. Wine's audio had to be piped through an ALSA compatibility layer into PulseAudio and then back out to ALSA. The stack shows how horrible this looks:

Hardware → ALSA → PulseAudio → ALSA emulator → Wine/Win32 → Windows app

Additionally the ALSA emulation layer (provided by PulseAudio) wasn't great. It would support a couple of channels and a few recording options but nowhere near as much as the ALSA that PulseAudio itself sat on top of.

The perceived problem was always "the other guys' fault"

Audio in Wine 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:

• Users clamoured for Wine developers to add a native PulseAudio driver.

• Wine developers didn't see why they should spend another age (and we're talking months and months of developer time) interfacing with yet another audio layer when they saw it as PulseAudio's problem for not providing a working ALSA interface. In their eyes people could just use pasuspender to get PA to release the lower-level ALSA for direct manipulation.

• PulseAudio developers also suggested that Wine should pull their collective finger out and just add a PA driver. Dozens of other applications had, so why couldn't they? And every time I asked, the PulseAudio ALSA layer was fine, without bugs and it was just Wine developers' own bugs that were the problem.

• A user wrote a hacked-in PulseAudio driver that spoke directly to Pulseaudio and did the bitmap audio conversion itself. Other users loved it because despite its hacks, it did often "just work" but Wine developers hated it because it was another large branch of code to maintain, and it was a hack.

And then things got better.

Everybody gave a little.

• Users stopped complaining as much.

• Wine refactored to use the Windows Vista and Windows 7 approach to sound. They call this MMDevAPI. You can read all about MMDevAPI here. This strips out a ton of sound code and simplifies settings. It still uses ALSA though.

• PulseAudio fixed bugs to allow Wine to work better.

• WinePulse's development ceased when MMDevAPI started to show that it was working.

And while it might seem like it, I doubt that's not the end of this story. There are commercially-supported projects like OpenAL and GStreamer that could really simplify Wine's sound stack as well as providing extra features.

But then years later, Wine 1.7.55 added mainline PulseAudio support...

I've been writing this post for years and this is perhaps the weirdest thing yet. After dropping the PA driver development, somebody appears to have gone back to this and turned it into something real.

More than that, it got pulled in to the mainline version of Wine.

In an established prefix, just run wine regedit and change HKCU\Software\Wine\Drivers\Audio from alsa to pulse. Everything —including surround sound— seems to work. Here's the stack now:

Hardware → ALSA → PulseAudio → Wine/Win32-api → Windows app

Is it any better than the ALSA compatibility layer? I'm still unsure. I've tried what I thought were some of the buggier games and they still skip around a bit.

It work though, which is the main thing... but so did the ALSA wrapper in the end.