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?