On Sat, Dec 5, 2009 at 12:50 PM, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am 05.12.2009 um 10:35 schrieb Chris Robinson:
Except it also has API-provided 3D features that would be a big benefit for implementing DSound3D,
This is indeed a big plus for OpenAL - if we use our own sound system we'll have to reimplement DSound3D features. It fits the "sit on the shoulders of giants" - use existing infrastructure instead of reinventing the wheel, which is usually considered good software engineering practice.
Personally I think DSound3D shouldn't be a high priority and I'm not sure if it is important for our design (DSound3D is more or less dead anyway for modern games). We need a stable sound system which is ready for the future.
I don't think it is wise to stay with the current win95 design and hack more stuff into it. Personally I think the best is to go for the Vista/Win7 design which means implementing mmdevapi/wasapi and layer winmm / dsound on top of that. For dsound3d we could create a IAudioClient3D or so. This is how it should be done in the long term.
Right now we are a couple of months away for a Wine 1.2 freeze. If dsound->openal works well enough it might be a good short-term solution but the code should be written in such a way that it would be easy to move it to a wasapi backend (I imagine that we will have an openal reference backend but next to that other backends like CoreAudio). Work can already begin on a wasapi implementation. It might be possible to have a basic wasapi implementation in wine 1.2 (winmm / dsound wouldn't use it). If people want they can use their vista/win7 dsound dlls if they own a windows license.
Roderick