Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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.

share|improve this question

1 Answer 1

up vote 11 down vote accepted

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:

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

  • Wine devlopers 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 to the present day. Things seem much better, so what happened?

Well 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, 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.

share|improve this answer
    
Excellent feedback. I mean excellent indeed. This is a complete answer to my doubt and I appreciate it. –  Luis Alvarado Dec 30 '11 at 21:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.