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

[Maarten Lankhorst]

Hi Robert,

Robert Reif schreef:
> I believe the approach you are taking moving openal into direct sound 
> is not a good idea and is going to create a lot of regressions that 
> can not be fixed with your current approach.
>
> Windows audio programmers know that they can get access to the same 
> hardware through multiple APIs at the same time.  That's because all 
> the APIs eventually go through the same driver to access the hardware.
>
> A common scenario for voip type applications using direct sound is to 
> find the corresponding wave device using the private property set  and 
> then find the mixer device from the wave device so they can get access 
> to the mixer volume to implement microphone AGC.
If pulseaudio is active, our mixer volume won't be much good anyhow. 
Happens on most installations already..

Looking at dns9 for example, it doesn't use dsound and combines it with 
mixing. It uses winmm waveout + mixer, ventrilo is quite a popular voice 
chat program, it still doesn't use the propset mapping, you have to 
select the mixer by hand.. I could try others, but not having a mapping, 
or a mapping thats invalid, is not that big a deal.
> The right approach for using openal is to develop an openal driver 
> like our current oss and alsa drivers.  That way all APIs will have 
> the same consistent view of the hardware.  The direct sound driver API 
> already supports multiple hardware buffer access so the software mixer 
> can be bypassed.
No, the right approach would be to finally create a WASAPI 
implementation, use openal there too, and kill off all our crappy winmm 
drivers and forward to wasapi instead. The headers to do this are mostly 
in place, and eventually this too will have to be done.
> You need to look at voip and audio conferencing applications.  You 
> also need to look at XP era utilities and games that came with boxed 
> Creative sound cards.  You could also try XP era openal programs using 
> the supplied openal dll which is just a thin layer over direct sound.
native openal32 -> dsound -> openal-soft already works properly, even 
builtin openal32->openal-soft + dsound->openal-soft is handled properly. 
And those boxed games would in the future even work better, since we 
could start supporting EAX extensions..

Cheers,
Maarten.