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

Chris Robinson chris.kcat at gmail.com
Fri Dec 4 01:20:33 CST 2009


On Thursday 03 December 2009 3:57:49 pm Robert Reif wrote:
> I believe the approach you are taking moving openal into direct sound is
> not a good idea and is going to create a lot of regressions that can not
> be fixed with your current approach.
> 
> Windows audio programmers know that they can get access to the same
> hardware through multiple APIs at the same time.  That's because all the
> APIs eventually go through the same driver to access the hardware.

FWIW, Creative has a dsound->openal wrapper for Windows called ALchemy that 
does pretty much what this is doing. It provides a dsound.dll that forwards 
dsound calls to OpenAL. Unfortunately it only works with Creative's hardware 
drivers (otherwise they risk getting an openal device that uses dsound..) and 
it's not open source. It's designed for XP-era and earlier software, to re-
enable true dsound acceleration.

> The right approach for using openal is to develop an openal driver like
> our current oss and alsa drivers.  That way all APIs will have the same
> consistent view of the hardware.  The direct sound driver API already
> supports multiple hardware buffer access so the software mixer can be
> bypassed.

An issue is that the current dsound driver setup just sucks. It's part of the 
reason why no one has added a Pulse backend, despite people willing to 
maintain one, AFAIK. I also don't think it handles properly forwarding 
DSound3D calls, so all that will be lost anyway.

Is it a problem if those other APIs (WinMM, WASAPI, etc) use DSound for device 
enumeration, output, and capture? They would maintain the same device list and 
homogeneous hardware access that way.

Another option is to put the dsound->openal wrapper in a separate driver, and 
make dsound.dll a thin wrapper to it (eg. DirectSoundCreate calls are 
forwarded, so there's no wrapper interfaces like with d3d9->wined3d). But then 
that pretty much leaves us where we would be with dsound as the wrapper, as 
far as apps and such are concerned. Does it make much difference if the other 
APIs use a very-dsound-like API from wine_al.drv, or dsound.dll itself?



More information about the wine-devel mailing list