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 features.
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).