The future of Wine sound

Sound in Wine has been a big issue.  From a user’s perspective, it didn’t work well.  From a technical user’s perspective, there were 3 different drivers to choose from and none of them worked well.  From a developer’s perspective, no sound driver would ever work well.

Wine was a victim of the proliferation of sound drivers on Linux.

At one point, Wine had separate sound drivers for ARTS, ESD, OSS, JACK, and ALSA.  None of them worked right, even if the user could figure out how to configure Wine to use the “correct” one.  Subtle changes to each API and differences between distribution versions made matters even worse.

PulseAudio was supposed to be a solution to problems like this by being the one true Linux Sound System, but in some ways it made the problem worse.  Now Wine needed a separate PulseAudio sound driver, and no one wanted to write sound driver code since the whole thing was a big mess to begin with.  Worse, the most work had gone into making the ALSA driver better, and there were a few technical reasons why it seemed like a good choice to stick with ALSA and use it as a default.*

So, the decision was made to go with ALSA and improve it a bit, and hope that PulseAudio’s ALSA-compatibility layer would work well enough.  That didn’t exactly happen – PulseAudio didn’t actually want to support some “abuses” of the ALSA API, as one dev put it.  Some users took to killing PulseAudio outright every time they wanted to use Wine.

Things got a bit political.  Was Wine at fault here, or PulseAudio?  Should Wine include a PulseAudio driver, even if it was poorly maintained?  What would the default be?  Also, what the hell were we gonna do about the Mac?

The solution, which in retrospect is pretty obvious

Wine wasn’t the only program facing this problem.  Anyone writing or porting a Linux game had to answer the question about how they would play sound – almost none chose to write 7 separate audio drivers.  Instead they all did the smart thing, and used a higher level library.

So, that’s the plan – Wine will use a sound library.  And then we’ll let them worry about actually talking to whatever sound system happens to be working best.  OpenAL is the smart choice here, for much the same reason that OpenGL was the smart choice for graphics.  We get Mac compatibility “for free” too.

Now, why didn’t this happen earlier?  Well, in fairness to Wine, OpenAL didn’t actually exist in a usable form until Wine already had sound drivers for a few years.  A similar thing happened with wikis and distributed version control systems – we eventually saw the light that new open source projects had been following for years, and the project is better because of it.

* As I understand it, a lot of Windows programs expected to be very close to the hardware and at the time many users were having issues with PulseAudio latency.


RonDecember 24th, 2009 at 7:40 am

Personally, I don’t want anything to do with Windows. There is just simply NOTHING about it or any programs that run in it that I cannot live without just fine by using Linux only. I just don’t understand the need for WINE. If one wants to run Windows apps, then run Windows on a PC, or run Linux with Windows in a VM and then run it from there, but to try and put Windows applications into Linux almost directly, to me seems absurd.

Vadim P.December 24th, 2009 at 7:41 am

Does OpenAL actually have PA compatibility, or is it ALSA?

Kai MastDecember 24th, 2009 at 8:07 am

Finally a way to fix this mess. Wine without Sound Problems would nearly be a wine without any problems for me.

@Vadim: I am fine running Linux. I only run Linux for 2 years. Still i have a lot of Windowssoftware (especially games) i wanna use once in a while. Additionally, i also have a lot of friends that would switch to linux if they could go on using their games they paid money for.

A virtual machine doesn’t help here because it emulates hardware, wine however can run recent games with nearly full speed.

In my opinion wine is the only way that Linux could get a major marketshare and Scott is doing a great job in helping with this. Thanks Scott for trying to fix bug #1 in launchpad for so long :)

JackDecember 24th, 2009 at 8:27 am

Sounds good to me =D

RobbertDecember 24th, 2009 at 9:23 am

@Ron: That Wine isn’t useful to you doesn’t mean it’s useless to all other users, for example I’m a happy Wine user. Furthermore there are various reasons why I wouldn’t use a Windows VM, first of all it requires me to buy a licence (and I refuse to spend any money on that), second of all the performance of Wine (especially with applications using 3d) is generally better. For a separate PC (or dual boot) the first reason holds as well, second I don’t want to buy another PC just for Windows applications…

So Wine is useful, at least to me! And I obviously hope that these changes to the sound system will make it more useful.

RonDecember 24th, 2009 at 9:41 am


but don’t you need to buy the licenses for the Windows software like Adobe Photoshop, etc?

Also, there are plenty of decommissioned WindowsXP boxes out there you could probably use a key from and run Windows in a VM. I see your points though, but after being the computing world for 31 years and after using every version of Windows made, I’m tired of the issues with it.

RobbertDecember 24th, 2009 at 10:10 am

@Ron: yes, even while using Wine one has to buy those licences (assuming Wine is used to run “paid” Windows applications), but it obviously avoids people from buying a Windows licence.

Getting a key from a decommissioned Windows XP machine often won’t either, most of those machines use OEM licences and to my knowledge it’s not allowed to use those licences on another machine.

I’m also tired of the issues with Windows, hence I don’t use it. But still I would like to play a game (which are often developed for Windows only) once in a while and then Wine is the perfect solution. A virtual machine probably won’t allow me that performance wise.

RonDecember 24th, 2009 at 10:55 am


Ever tried CrossOver? I heard it’s like a commercial version of WINE with even better support. May resolve the sound issues.

Kelly ClowersDecember 24th, 2009 at 11:53 am

Vadim P: I don’t know what OpenAL’s requirements are, but there may be no reason for it to use the PA API. When possible, PA users are encouraged to use the “safe ALSA” api, a subset of the full ALSA api, to talk to PA. Of course, it might be that OpenAL needs features only accessible via the PA API…

AlexDecember 24th, 2009 at 12:26 pm

Finally. The fewer things that talk directly to ALSA (or OSS, or PulseAudio), the better.

StoffeDecember 24th, 2009 at 12:47 pm

If you are a gamer, Wine is almost a must for the long term actual switch – not Wine as it is today, but great, stable, compatible Wine as it may be at some point in the future.

What most everybody who is not a gamer does not realize is that games are not like applications. (Win32) games are like *documents*. Specifically, documents that “opens” with the Win32 API, just like Word documents opens with Word.

The usual argument you hear is that games in the future should be made for Linux directly, and conversely that with the market share comes the games, etc. Well, here’s to hoping – but that is at least partly false reasoning – and the “failure” to support already existing games may even be contrary to that goal ever being achieved.

Since games are like documents, it’s a very different story from all other compatibility issues – at one point, users were perhaps forced to use Office because nothing else could open their work stuff – maybe even because nothing else was good enough to create the documents. Enter and others, which can open all the old documents that the company has, and a switch becomes more possible.

For games, if all games started to come for Linux starting tonight, what would that help my huge collection of old documents, er, games that I already have? Absolutely zero. There are lots of games that may be a decade or even two old, that still give better value that most of what’s coming out today, and that is important. This is why console emulators are still so popular, for nes, snes, mame (and dosbox), scummvm and so on.

There are just so many great games that we want to return to, and here’s the important part: no matter what happens, no matter if the whole world switches not only to Linux, but to a specific distro, flavour, DE, even the same hardware (or all to Macs, for that matter) these games will never be converted, and even more so, you will not get the new versions even if they would be.

For non-gamers, this is a non-issue, and any other Windows app *can* be replaced by a Linux one, especially if the format is made compatible.

For games, the app is Win32. For gamers, this is absolutely *crucial*.

I understand that non-gamers don’t see this and don’t see the point in investing time/money in Wine. For gamers, a *well-working* Wine that just works would be the holy grail. Anecdotally, that’s just about the only reason I ever hear from just about everyone as to why they don’t even usually try Linux, even though they hate Windows and love the bling, look and everything else. It’s also the first question the anecdotal “everybody” asks me everytime I say that I don’t use Windows. “What about the games?”. “I can’t run them”, I say. Which is generally the truth, there’s a small bunch of “supported” games that do work, but the rest is hit-and-miss and rarely worth the effort anymore.

Personally, I think that Wine, overlooked and belittled as it is, may be *the* killer app, *the* Bruce Dickinson, the fix to bug #1 if enough effort went into it. then again, it may not be – but it’s important to note that the people calling the shots seem to have almost zero overlap with the huge mass of people I am referring to as gamers, above. So it may just be that they simply don’t see this. Hell, *everyone* plays games these days, and consoles or no, a lot of it is still on Windows. And everyone that has grown up today has played the games. It may just be huge.

Or it may not. but I sure would like to see what would happen if just *perfect* XP support was there… =)

MorganDecember 24th, 2009 at 2:23 pm

I use wine for a few games and the games that do work in wine are often faster that in real Windows (XP) on the same hardware.


Max payne (the original)
Call of Duty (1+2) – its so much faster in wine – and it uses D3D…
Civ4 – renders a lot quicker in wine than Windows (not that it matters in this game)
– I have AA turned off in both winblows and Linux.

RDecember 24th, 2009 at 4:59 pm

I actually use WINE + the so called unsupported pulseaudio package (there is a PPA out there).

It works brilliantly. And sound was always a nightmare. Even without pulseaudio.

tankDecember 28th, 2009 at 6:19 am

ReactOS can fix that issue in future…

unproductive_wine_devsJanuary 6th, 2010 at 4:21 pm

to me it seemed like:
- I want to make a pulseaudio driver to put into wine and are really motivated to do it!!
devs – no. (insert idiotic reason here)

way to kill motivation… if he wouldn’t maintain it you simply remove the driver again saying it’s because of resource problems. I guarantee you would get someone motivated to maintain it within a week of publishing that. Now, instead of *fixing* the problem you are basically saying:
- let other people deal with it.
or am i wrong and everything would get fixed if you made an openal driver? if so please tell me because this certainly seems inane.

PS: the pulseaudio guy seem to have proven himself already if “R” is right.

thomy44January 7th, 2010 at 9:51 am

I think in the same way like Stoffe,

Linux with a perfect wine for win32 games would be THE KILLERapp!!!
Especially the young Gamer generation is curious…

It would be the same like Mozillas Firefox…. its killing the fucking IE ! Because it absolutely compatible. And lets see, Open Office will kill microsofts office!

So, thanks for working at the wine sound!

NexonJanuary 14th, 2010 at 4:18 pm

Is there something like a “Roadmap” for the OpenAL-Integration?

Psy[H[]January 16th, 2010 at 12:08 am

I hope they would not waste resources for something like pulseaudio.
Current pulseaudio craze will pass when insanity of the concept becomes obvious. A big and heavy additional layer, far outside the kernel, that would mix all the sound in low latency, even under high cpu load, and output it through existing soundsystem (alsa)? Nonsense. Its latency is so big that it is even noticeable with naked ear. For some apps it just garbles sound. Run doom in dosbox, or zynaddsubfx and hear for yourself.
That is what happens when someone adds additional layer of mess to cover existing mess.
Why not to improve alsa? why stack the new problem over it and send sound through both?

Bill GatesJanuary 20th, 2010 at 9:23 am

I’m with Nexon – when can we expect to see a version of Wine with integrated OpenAL?

DrHalanFebruary 2nd, 2010 at 8:43 am

@Nexon: I want to know that too!

Is there a git branch or somethign to checkout the development of OpenAL In wine?

Endre StølsvikFebruary 10th, 2010 at 11:57 am

I agree TOTALLY with @unproductive_wine_devs above. There *is* a patch that fixes all problems, at least for Ubuntu as it stands. But it is not applied.

So a “short term gain” of about, well, OVER ONE YEAR, is not enough to make the Wine devs happy – no, lets start all over again instead – on a completely uncertain time schedule.

How arrogant. How stupid.

PerFebruary 15th, 2010 at 2:39 pm

The only way I’ve got sound to work almost flawlessly in Wine is to use OSS. It runs pretty well, and sounds really good. I run Steam-games like Source-games and Fallout 3, I run Spotify etc. Unfortunately OSS aren’t very well supported in various Linux-apps, for example; one needs to reactivate ALSA to run most sound editing apps. And if one does that, the sound in Wine is back to buggy again. It’s a catch 22. And it’s tiresome to switch back and forth between various sound architectures. Pulseaudio ain’t worth mentioning, it’s buggy as hell. To me, sound is still a major showstopper for a total Linux switch. It should be the highest priority to unite around ONE sound architecture that everyone has to use, app makers and distros alike, fragmentation is evil.

YokoZarFebruary 15th, 2010 at 4:26 pm

Endre, if you read my comment at the bug report I explain how not including the winepulse driver was a conscious decision on my part as a result of testing. This is part of my responsibility as a packager. Listening to upstream is another part, and the consensus among the Wine developers is “no, don’t.”

At any rate, it wasn’t ready in time for Karmic, and I’ve been reevaluating it again in the Lucid cycle. For now, though, I’m waiting on Maarten Lankhorst’s OpenAL patches, which as I understand are very near ready for inclusion.

SawnJuly 22nd, 2010 at 3:25 pm

great article about ‘The future of Wine sound‘,. Thanks

leighmanSeptember 30th, 2010 at 2:22 pm

There’s a repo at if anyone is interested.

[...] Ritchie: The future of Wine sound. If you’ve tried running apps under WINE that uses sound you know it’s definitely not [...]

Leave a comment

Your comment