[Openal-devel] 1.1 Confusion

[Garin Hiebert]

You're right about the docs.  We'll be re-working all the enumeration/ 
deployment documentation soon.

> You mentioned that we should enumerate devices and pick only the  
> 1.1 implementations. Is there currently any such thing as a native  
> 1.1 driver right now, from Creative or NVidia or anyone else? Or  
> would this simply be for "future proofing" so our app would be able  
> to use them once they appear?

I only mention it for "future proofing"  -- neither NVIDIA nor  
Creative have released 1.1-compliant native implemenations.  They are  
in the works, however.

Thinking about it on the drive home tonight, I think my earlier  
explanation was OK but overly complicated.  You could just do the  
following, which in fact was what we assumed someone would want to do  
with the 1.1 Beta SDK:

Put the OpenAL library from the SDK into your application's  
directory, and use it from there.  That way, your beta 1.1  
implementation isn't interfering with the 1.0 implementations in your  
system directory.  This would also work for real deployment, but  
wouldn't give you access to 1.1 native libraries.

If you want to emulate what your system will look like when the 1.1  
router and wrapper go into the mainstream installer:

a)  Compile the router library from CVS HEAD and dump it in your  
system directory, replacing the 1.0 implementation.
b)  Rename the AL library from the Beta SDK to "wrap_oal.dll" and put  
it in your system directory, replacing the 1.0 implementation.  (An  
alternative is to compile the wrapper in CVS HEAD and use that one,  
but it doesn't have the more advanced EAX extensions in it.)
c)  Enumerate all devices and ask for the default.  Open each device  
and ask it if it is a 1.1 implementation, then close it.  If the  
default is not a 1.1 implemenation, then make the default "Generic  
Hardware."
d)  Now your app can either just use the default blindly, or present  
the user with a menu showing the "1.1 list," with the default selected.

> >so things aren't anywhere near as bad as "Mesa versus native OpenGL"
> That's a point of major interest, probably to lots of developers.  
> What kind of performance difference are we talking about between a  
> "native" OpenAL implementation vs. the generic CVS reference  
> implementation? Assuming we're not using vendor-specific  
> extensions, and are only talking about performance differences,  
> what do we really lose by going generic vs. native? A factor of 2?  
> Less?

_Maybe_ a factor of 2 for a few specific operations, but for the most  
part much less than that (for Creative native implementations versus  
DS3D).  Comparing with the software mixers, the main difference isn't  
performance, but higher quality mixing, higher quality interpolation  
(8-point in our newer hardware versus 2-point for sofware).  When you  
get into the world of effects (EAX), then there is a noticeable  
impact on the CPU.

> Simply as a "head's up": I just downloaded the OpenALSDK.zip again  
> from developer.creative.com, and in the alc.h in the \include  
> directory in this download, the capture functions are there in the  
> header, starting on line 99 with alcCaptureOpenDevice. They're also  
> in the lib, but not in the DLL, so trying to use them is futile.

That's a total screwup on my part -- I'll put up the proper SDK  
tomorrow.  Thanks for the info...

Garin