Wine sound discussion summary - wine-devel

6 Dec 2009


      Hi,
For those who didn't follow the big dsound argument thread, here is a quick summary of the main points. I originally inteded this as a summary mail, but while collecting the arguments I have instead taken the discussion off-list accidentally. But here's the current state:
Pretty much everyone agrees that the current sound infrastructure is broken. In terms of how to fix it, there are 3 points to be worked out.
1) Use OpenAL or a more sophisticated driver infrastructure
2) If no OpenAL, what do we use
3) How do we get there.
I'll mostly focus on (1) here, as the others depend on the decision of (1). On Wineconf we decided to give killing our entire sound infrastructure a try and replace it with a winmm and dsound based on OpenAL. That wasn't a promise by Alexandre to commit it, more an investigative study.
The advantages of that would be:
* A compact Wine sound system, we don't have many different sound drivers. OpenAL is available on all operating systems
* We can let Linux(dmix, pulseaudio) do some or all of the mixing(with openal.so improvements)
* Outsource workarounds for Alsa/PulseAudio/Coreaudio bugs to openal
* Supporting DirectSound 3D is easy - openal just has it available. No need to reinvent the wheel. There are still a lot of dsound 3d games from WinXP and earlier.
* Hardware accelerated 3D sound is possible. Currently there are no Linux drivers for that though.
* Winmm, dsound and Windows openal.dll interaction still works fine as long as all libs interact with openal in the same way
Disadvantages:
* We have less control over our sound infrastructure and might get into troubles if some apps depend on the underlying driver system
* We depend on the system openal. Linux distros have to keep their 32 bit openal updated. Getting bugfixes shipped to users might take years. MacOS OpenAL seems pretty broken.
* Outsourcing bug workarounds is a slippery slope. It will be hard or impossible to work around problems without openal and distro help(and we need help again to get them fixed properly).
* OpenAL is essentially just an abstraction layer not any system's native way to do sound.
* Dsound 3D is dead in Win7, maybe  we shouldn't focus our design decision on it
2) If no OpenAL, what do we use
The consensus is mostly that if we don't use OpenAL for abstraction then we would aim for the Windows 7 sound driver API, or something very close to it. The goodies include
a) Its the way Windows does it.
b) If Win7 has user space audio driver support we might be able to use those drivers
c) Technically native dsound and winmm might work, which can be helpful for debugging
d) No bad surprises when apps start screwing around with the internals(e.g. load an DRM decryption APO into the sound processing chain).
Problems of this sound infrastructure include:
* It is very complex and maybe a lot more than we need.
* The Windows 7 sound model mandates software mixing. We'd have a audiodg.exe process running that mixes all streams from all processes. Add in pulseaudio or dmix, and maybe dsound has to do its own mixing and you have 3 software mixers in a chain. But maybe that's a place where we can deviate from the MS design, or use mixing plugins provided by our drivers.
* It rules out hardware accelerated dsound3d. Although a user might install Creative's openal wrapper or similar software to get back HW dsound 3D in the windows 7 way, with all its pros and cons. Most new 3D sound games use openal natively.
* For full compatibility to drivers and native libs we'd need the DDK, and nobody checked the license terms so far.
3) How do we get there.
This obviously depends on what we do, and we probably won't do much before the 1.2 release. For the OpenAL way, we could just throw in the code Maarten wrote so far, or Chris' Dsound->OpenAL wrapper.
For Win7, one idea was to implement one more Win 3.1 sound driver in Wine that is based on the Win7 infrastructure, then implement that infrastructure and move winmm and dsound over. Once this is done, throw out the old Win 3.1 stuff.
Or implement the Win7 infrastructure and maintain a separate dsound and winmm off-tree(developed on Windows), and put them in place once the Win7 driver infrastructure in Wine is solid enough.