[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