Wine sound discussion summary

[Stefan Dösinger]

Am 06.12.2009 um 14:20 schrieb Reece Dunn:

>> * 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.
One thing to consider is that if old games break in Windows, people will write their own compatibility layers to fix that. Take for example the Glide->OpenGL wrapper, or the dsound->OpenAL wrappers that are out there and get these games working on Win7 with all the old features. We don't have a disadvantage compared to Windows if the same fixes work in the same way on Wine. We do however have a disadvantage if new apps don't work because we stick to old solutions for old apps. We killed a few Win16 and Win95 hacks in the past.

>> * 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.
Actually, in many places we say that if an old app doesn't work on Wine and fails in the same way on some sort of "reference" windows version(currently probably XP, in a few years Windows 7), then letting the application fail is the correct thing to do. If its easy to get it running do it, but don't go to extreme lengths. For example, we don't support the Windows 95 memory management which breaks a lot of old apps.

>> 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.
This is correct, and at times I have argued against trying to support other Windows drivers(e.g. 3D drivers). However, extra features that aren't the primary goal but still interesting aren't a drawback in my eyes. Being able to use Windows drivers definitely isn't our primary concern though.

> 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.
This is something we've discussed on IRC a bit today. In fact, implementing the whole Win7 stuff with the audiodg.exe mixer process won't work - it will require lots of IPC, add latency and make games unplayable.

See below for more:

> 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?
Yes, there's one new DLL for playback and one new DLL for sound card configuration - e.g. notification if a bluetooth sound card is added, PNP enumeration.

We have to implement those new DLLs. However, do we reimplement the old DLLs on top of the new ones like Windows does(e.g. dsound.dll and winmm use the new Win7 sound DLLs) or just make every of our DLLs call OpenAL directly. (My personal opinion is that we have to keep the Windows way on the DLLs that can be considered the app frontend)

Those new DLLs add a bunch of new features, like per-stream volume that more or less require a sound server like pulseaudio(Windows 7 has audiodg.exe, XP already had kmixer). That has some implications too.