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.