[PATCH 1/7] dsound: Remove support for IKsPropertySet for now
m.b.lankhorst at gmail.com
Fri Dec 4 09:00:45 CST 2009
Robert Reif schreef:
> The current wine direct sound implementation can do multiple opens of
> the same device and hardware mixing and hardware 3d acceleration
> without any modifications if the low level driver supports it. No
> wine audio driver implements all that because the linux audio APIs
> don't support it. An openal driver can be developed which can
> eventaully replace the alsa and oss drivers and supports everything
> you would expect on a real windows system. A total rewrite of the
> entire audio system from scratch might be better in the long run but
> just adding an openal driver doesn't require changing any of the
> existing wine code, it only adds a new driver. Writing an openal
> driver is probably a half a man year effort to get working well enough
> to make it the default driver. Doing a total rewrite of all wine
> audio APIs to move
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
If you look at our driver code, they all do EXACTLY the same crap,
except they're in various stages of decay. I don't call that a good
thing to base our code on. Especially since they all have the same buggy
ring buffer implementation that for some of them might still end up
being dead locked since a message is missed.
> them from the Windows 95 driver model to the current WDM driver model
> is probably a 5 man year effort to get working right. Your approach
> may make some direct sound games work better but it is going to
> introduce a lot of unfixable regressions.
You mean implementing mmdevapi? Could be done in under 3 months, with
time spare to do the wine7audio driver..
> The current wine audio implementation does a pretty good job of
> implementing the windows 95 audio model. It's not the direct sound or
> winmm dlls that make audio suck in wine, it's the alsa and oss drivers
> that suck and that's because the alsa and oss APIs and their low level
> drivers suck (and pulseaudio would suck even worse). An openal driver
> would allow wine to support all the features that the current direct
> sound implementation already supports but can't use because of current
> alsa and oss driver limitations.
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.
More information about the wine-devel