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

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 12 down vote accepted

There really 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 ages for the ALSA support to a just works stage but once it was working, it worked pretty well. If you want a stack diagram, it's very simple:

Hardware → ALSA → Application

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

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.

These were both quite popular ideas before MMDevAPI but they've stalled a little since.
One day, maybe.

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.