[Openal-devel] 1.1 Confusion
garinh at cheesetoast.net
Thu Sep 8 23:00:22 PDT 2005
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
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?
_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...
More information about the Openal-devel