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

Chris Robinson chris.kcat at gmail.com
Sat Dec 5 03:35:02 CST 2009

On Friday 04 December 2009 3:53:46 pm Stefan Dösinger wrote:
> Am 04.12.2009 um 18:51 schrieb Chris Robinson:
> > Though you'll still need a way to talk to the hardware. Using
> > ALSA/OSS/etc directly has proven problematic with not only the current
> > design and upkeep, but properly implementing various features. Not that
> > I'm advocating PulseAudio here, but it is closer to how the Windows audio
> > stack is, and it's put in quite a bit of dedicated work to get where it
> > is.
> Well, from that point of view OpenAL is just another abstraction layer, if
>  you don't happen to have a creative card with native openal support.

Except it also has API-provided 3D features that would be a big benefit for 
implementing DSound3D, and has a defined API that can be re-implemented to 
best take advantage of the user's system (I still imagine someone making an 
implementation that off-loads storage and mixing into PulseAudio's server; 
just imagine that, where each DSound Buffer represents a stream that is mixed 
remotely and efficiently, and completely inline with the rest of the system). 
And Wine wouldn't have to lift finger to get it.

>  While
>  I usually agree with using a system provided abstraction layer for average
>  apps, I think Wine has many low level needs that are tough to satisfy
>  through an abstraction layer. If you hit a driver bug somewhere in an osx
>  driver its easier to work around it with a coreaudio backend than through
>  openal.

That's true. But at times, I still think it's better to use the existing APIs 
for proper integration, where it counts. It will give Wine a boost for not 
needing to maintain a separate audio stack, and it also improves OpenAL 
implementations by testing them and extending them with useful requested 

You hit a bug in OpenAL, then OpenAL can (and should) be fixed. When OpenAL 
gets fixed, then Wine is implicitly fixed along with other affected apps. But 
if Wine uses its own stack built on the hardware and a bug crops up, you need 
to wait until someone can fix Wine. Just look at the situation with PulseAudio 
to see what I mean (OpenAL has supported Pulse for the last few versions, when 
we're not trying to break each other; Wine still doesn't properly support it 
because the driver interface is a mess that noone's willing or able to fix).

Ever since the openal dll thunk was first made, and I implemented the original 
dsound->openal wrapper, I've been able to significantly improve (and am still 
improving) the Linux version of OpenAL, which has helped DSound-based games. 
It will also be a big help when work is done to implement EAX, as it will help 
push its EFX implementation; helps OpenAL, and it gets EAX support for DSound 
games. Improving OpenAL will help it get support from other software 
developers, which will provide Wine with new features and better tested code.

> I also don't trust the OSX OpenAL implementation. Using your openal thunk
>  with Trackmania on OSX I get broken sound and random stack corruption. I
>  didn't investigate much yet, and just tested with one game, but it
>  certainly leaves a bad first impression(the Linux SW openal with your
>  thunk works perfectly with this game)

Understandable, but at the same time, it gives something to Apple to improve 
their OpenAL implementation with (especially if you're getting stack 
corruption, which sounds like a potential security issue).

More information about the wine-devel mailing list