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

[Robert Reif]

I don't have issues with what Maarten is trying to accomplish.  In fact 
I'm happy to see someone making a serious effort to fix wine audio.  
What I do have serious issue with is the way he is attacking the problem.

The windows 95 driver model is not a bad model.  If you look at the 
winmm driver API and the winmm API, they are virtually the same.  The 
same is true for the direct sound driver API and the direct sound API.  
Under ideal circumstances the winmm and direct sound dlls are doing 
nothing but marshaling between user space and kernel space.  An 
application is virtually interfacing directly with the audio driver.

The problem with the windows 95 driver model is that the user experience 
depends totally on the quality of the sound driver and sound hardware.  
If the hardware doesn't do something, an application using it also can't 
do it.  Microsoft redesigned their sound system to provide consistent 
audio capabilities regardless of the hardware capabilities by placing 
software between the drivers and the APIs to change whatever the APIs 
requested to something the hardware can handle.  Also because all audio 
drivers were virtually the same, they also refactored the audio system 
to place common code in intermediate software layers. 

The problems Microsoft had are the same problems wine currently has: 
inconsistent audio experience.  Wine audio works fine for some people 
and not at all for others because the hardware and operating system and 
audio API they are using are different.

The approach Maarten is taking by starting with direct sound is 
backwards and will cause serious regressions.  You can't just throw out 
working code that applications use just because most people won't 
notice.  Maarten has admitted that he will have to develop an openal 
winmm driver but not right away.  What he should do is develop that 
driver first and get it working well along side the current drivers.  
This won't immediately help direct sound but direct sound will be able 
to use it.

The next step should be to decide if we want to use openal as the one 
and only audio API in wine.  If so, then we have two approaches to do 
that.  We can add a direct sound API to the openal winmm driver just 
like we do with existing drivers or put openal code in the direct sound 
dll.  If we are absolutely confident that the openal winmm driver can 
operate properly with the openal direct sound dll at the same time, then 
that would be a reasonable approach.  The only down side is that audio 
code is not centralized. If state needs to be shared between the two 
APIs, then a single driver is the best approach.

The big problem with the current direct sound dll is that it must do 
software mixing and format and sample rate conversions when the low 
level driver doesn't do what the application requested.  In wine, none 
of the drivers can  do what is requested. If the low level driver was 
guaranteed to do anything the application requested, we could remove 
that code.  Then we are down to just marshaling between the app and the 
audio driver or API.

We need a design approach and a road map and an agreement that the 
approach is correct.  We also need to insure that regressions are not 
introduced during the process.  I would like to see an incremental 
solution that doesn't introduce regressions.  That is developing an 
openal winmm driver first and then address the best solution for the 
direct sound issue later.  Not the other way around.