[PATCH 1/7] dsound: Remove support for IKsPropertySet for now

[Stefan Dösinger]

Am 04.12.2009 um 18:51 schrieb Chris Robinson:
> Though you'll still need a way to talk to the hardware. Using ALSA/OSS/etc 
> directly has proven problematic with not only the current design and upkeep, 
> but properly implementing various features. Not that I'm advocating PulseAudio 
> here, but it is closer to how the Windows audio stack is, and it's put in 
> quite a bit of dedicated work to get where it is.
Well, from that point of view OpenAL is just another abstraction layer, if you don't happen to have a creative card with native openal support. While I usually agree with using a system provided abstraction layer for average apps, I think Wine has many low level needs that are tough to satisfy through an abstraction layer. If you hit a driver bug somewhere in an osx driver its easier to work around it with a coreaudio backend than through openal.

> Plus when you consider integration, having home-grown layers on top of 
> hardware doesn't work that well. GDI/Direct3D wouldn't be where it is now if 
> it didn't have Xorg/OpenGL to integrate into the user's graphics system. 
OpenGL are X11 is the lowest hardware vendor independent graphics and 3D interface. If we didn't use them, we'd have to rewrite driver for each GPU and would call our project ReactOS and not Wine. If we don't use OpenAL, we still don't have to implement HW drivers ourselves.

I also don't trust the OSX OpenAL implementation. Using your openal thunk with Trackmania on OSX I get broken sound and random stack corruption. I didn't investigate much yet, and just tested with one game, but it certainly leaves a bad first impression(the Linux SW openal with your thunk works perfectly with this game)

If all Linux drivers(including the proprietary ones) offered the Gallium3D interface which is more low level and not something a Linux game would use, I'd still use it for Wine - its much easier to use it for our needs than opengl(easier in the sense that you have better HW control and don't have to lobby for extensions). Plus, we're already using lots and lots of vendor specific GL extensions instead of the ARB standardized stuff which is often only available on the next generation of GPUs for similar reasons.