Wine sound discussion summary

[Reece Dunn]

2009/12/6 Stefan Dösinger <stefandoesinger at gmx.at>

> 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:

Nice summary.

> 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

For any solution (OpenAL, Win7, other), I would say that having a
unified audio codepath (like WineD3D does for ddraw/d3d) is a good
thing.

> * 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.

This is good, as those older games will then sound better on
Linux+Wine than they do on Vista/Win7 with its default drivers. That
is, the 3D effects in Diablo 2 and other games should just work.

> 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).

There will be bugs in alsa, pulseaudio, oss4, openal, etc. that any
adapter/abstraction layer will need to cope with. The key question is
whether the benefits of creating and maintaining a wine-specific audio
layer (like is done at present, with the duplication of bug-fixes for
the different backends) outweigh the benefits of using an appropriate
backend such as OpenAL.

> * OpenAL is essentially just an abstraction layer not any system's native way to do sound.

This is true (in that it is like alsa, oss3, oss4 and the Windows/Mac
audio driver layers), but is largely irrelevant. The key question here
is how OpenAL interacts with the native system audio (i.e. how does it
interact with alsa, oss and pulseaudio).

> * Dsound 3D is dead in Win7, maybe  we shouldn't focus our design decision on it

So. There are older games that are making use of dsound 3d, so it is
not a deprecated API that no-one used.

I thought Wine's policy was (in addition to getting Windows
applications running on Linux/Mac/BSD/OpenSolaris/etc.) that it aims
to support older applications, which means that if there is a way to
properly support dsound 3d then Wine should support dsound 3d,
irrespective of Microsoft's decisions to drop 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.

It is the way that Windows does it *now*. There is no guarantee that
Windows 8 or later might do something different.

> 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

Wine isn't out to support the Windows driver model, it is aimed at
supporting Windows applications and the Windows APIs that those
applications use.

> d) No bad surprises when apps start screwing around with the internals(e.g. load an DRM decryption APO into the sound processing chain).

What about applications that are dependent on the internals of
pre-Vista Windows audio?

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

If Wine is going to go down the Windows 7 audio route, why not
redirect everything to pulseaudio? Then you don't need yet another
software mixer and you get the different applications showing up in
the pulseaudio volume control mixer.

> * 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.

Most new games use OpenAL to get hardware acceleration for audio since
Microsoft broke hardware accelerated audio in Vista and later.

> * For full compatibility to drivers and native libs we'd need the DDK, and nobody checked the license terms so far.

Also:, the driver APIs are not guaranteed to be stable from one
version of Windows to the next.

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

Agreed. The current sound system is not perfect, but has been tested
extensively.

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

With the Vista/Win7 model, are there any new front-end audio APIs that
applications can make use of, or is it still winmm+dsound?

- Reece