[PATCH 1/7] dsound: Remove support for IKsPropertySet for now

Maarten Lankhorst m.b.lankhorst at gmail.com
Fri Dec 4 09:00:45 CST 2009


Hi,

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 
aspect.

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.

Cheers,
Maarten.



More information about the wine-devel mailing list