[PATCH 1/7] dsound: Remove support for IKsPropertySet for now
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.
> 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
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