[openal] "Performance" Question

Chris Robinson chris.kcat at gmail.com
Sat May 31 02:40:41 EDT 2014

On 05/30/2014 10:39 PM, developer at oldunreal.com wrote:
> And yes, it should be compatible, but for some yet unknown reason I get
> reports that it doesn't seem to in every case.

OpenAL Soft is a bit more strict when it comes to spec compliance. There 
are things Creative's drivers just ignore where OpenAL Soft more 
correctly generates an error. Using al* functions without a current 
context, for instance -- Creative makes it no-op and returns 
AL_NO_ERROR, while OpenAL Soft makes it a no-op but returns 
AL_INVALID_OPERATION since the call couldn't be done.

There's also things Creative's drivers allow simply because of how it 
handles things internally. For example, you can queue a STEREO16 buffer 
and a STEREO_IMA4 buffer both onto the same source because IMA4 is 
decompressed to 16-bit, but that's not something guaranteed by the spec. 
OpenAL Soft keeps track of the original format that was passed to 
alBufferData and ensures they match.

There are a few extensions as well that OpenAL Soft doesn't support, 
like EAX or EAX-RAM. A number OpenAL apps on Windows also hard-code 
device names of DirectSound3D, DirectSound, Generic Hardware, or Generic 
Software, which come from the wrap_oal driver and aren't recognized by 
OpenAL Soft.

So there are certainly places where a poorly written app, or an app that 
relies on "obscure" extensions, can work with Creative's drivers and 
trip up with OpenAL Soft. In the general case, though, it should work.

More information about the openal mailing list