[PATCH 1/7] dsound: Remove support for IKsPropertySet for now
stefandoesinger at gmx.at
Fri Dec 4 09:50:59 CST 2009
Am 04.12.2009 um 16:00 schrieb Maarten Lankhorst:
> I'm NOT going to touch our winmm drivers any more apart from maintanance. I am willing to make 1 more, 'wine7audio' that forwards to IAudioClient, and does all bizarre things like looping wave packets, etc there, so our audio will be sanitized. After that all our other 3.1 era winmm drivers will die. The windows 7 api is a lot cleaned up in that aspect.
I like this idea - that would allow us to implement a clean Windows 7 sound driver system without breaking things in between. Dsound and winmm can be gradually moved over to the win7 system, and once that is done the old win3.1 sound system can be removed.
> Nobody uses the drivers as they are implemented, since nothing can depend on how windows implements them, it changes every major release. Not a single program can look at the dsound internals, which is why something like alchemy on windows works, which is exactly what we do here.
I'm afraid these are famous last words. Apps rely on all sorts of strange things that are different between Windows versions. And if they're different, they implement two different codepaths for Win XP and Win7, etc.
Wrt OpenAL, I am opposed to using it for our sound system. I think its a good idea for the transition to Win7, as a first driver and probably later reference driver. But I think we need an exit strategy to get rid of OpenAL as a hard requirement once the transition is done.
The reason is that getting bugs fixed in 3rd party libs is a pain, and making distros update 3rd party libs is even a bigger pain. OpenAL is a multi-vendor standard. If it turns out that we need some extension for a dsound speciality it will take a lot of lobbying work to make Apple support it. The Linux side will be much easier, but it will take years before distros pick up the change and users pick up the new distros. So we won't be able to rely on this for a bunch of years.
(E.g: On the GL side look at GL_EXT_direct_state_access, or the additions I made to binutils and gcc for the Steam overlay)
More information about the wine-devel