[openal] "Performance" Question

[Chris Robinson]

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.