Jump to content
  • Advertisement
Sign in to follow this  
paulecoyote

[OpenAL] Redistribution / Installation

This topic is 4833 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was developing last night on my laptop and my openal application was throwing a null/bad pointer exception within alcOpenDevice(NULL)... passing alcOpenDevice("") got a little further but not much. Before checking out on the laptop, on the other computer the application worked fine. But there were no devices when attempting to enumerate, just an empty "" one. So I flailed around trying to figure out what I did wrong, when I realised something. Although I had the openal source built from cvs, and it was linking with the dlls without a problem - I had not installed the redistributable. Installing the redistributable from Creative and it enumerated devices properly and everything. Now I was under the mistaken belief before that whatever is in cvs is all that you need, but it seems that some other Windows poking is needed to actually get Openal going, not just distributing the dlls built from source. So is there somewhere that says what you need to do to build your own installer? Because it's either that or redistributing Creatives installer and getting the user to install more then one thing. And if any 4E4 judges are reading this, would supplying the openal installer from creative as part of the installer for an entry loose any points? If it does not that I see no reason (apart from academic, and perhaps if it bugs you) in creating a custom openal installer. EDIT: Come to think of it I might have changed something that might have broken it? The openal project I changed so it outputs openal32_d, and wrap_oal_d.dll rather then without the _d to make an easily seen difference between a debug build and release build. The debug build of my project links to all debug builds of everything that it uses: 14/08/2005 04:16p 720,896 boost_regex_vc7_mdid.dll 14/08/2005 04:16p 27,136 ogg_d.dll 14/08/2005 04:16p 69,632 OpenAL32_d.dll 14/08/2005 04:16p 711,168 taglib_d.dll 14/08/2005 04:16p 892,928 vorbisenc_d.dll 14/08/2005 04:16p 35,840 vorbisfile_d.dll 14/08/2005 04:16p 1,081,344 vorbis_d.dll 14/08/2005 04:16p 135,168 wrap_oal_d.dll ... the release build links to all this 14/08/2005 04:16p 479,232 boost_regex_vc7_mdi.dll 14/08/2005 04:16p 12,800 ogg.dll 14/08/2005 04:16p 32,256 OpenAL32.dll 14/08/2005 04:16p 290,816 taglib.dll 14/08/2005 04:16p 1,019,904 vorbis.dll 14/08/2005 04:16p 884,736 vorbisenc.dll 14/08/2005 04:16p 20,480 vorbisfile.dll 14/08/2005 04:16p 77,824 wrap_oal.dll ... Is it possible that because I only built the debug version on the laptop that somewhere in openal it looks for specifically named dlls dynamically loaded, and because they are named different it does not work without the redistributable? And that's why it did not work?

Share this post


Link to post
Share on other sites
Advertisement
Well in this case it was RTFM... well at least partially anyway.
http://www.openal.org/windows_enumeration.html

Quote:

Introduction
Enumeration allows an OpenAL application to determine what output devices are available for OpenAL to use. Without enumeration, OpenAL will output to whatever device is selected in Windows as the preferred output device. Using enumeration, the application can present the user with the option of selecting a device other than the preferred output device or allow selection of alternative implementations.

This document will go into detail explaining how the enumeration extension works under Windows. The enumeration extension is supported by the library installed by the OpenAL Installer distributed by Creative Labs. The Windows part of the OpenAL source tree contains all the source code.

Note that an OpenAL programmer does not have to be aware of this material to make a good OpenAL application. This information can be handy for understanding how to deploy and debug OpenAL applications, however.

Usage

This extension provides for enumeration of the available OpenAL devices. If the extension query (for ALC_ENUMERATION_EXT) returns AL_TRUE, then an alcGetString query of ALC_DEVICE_SPECIFIER with a NULL device passed in will return a list of devices. Each device name will be separated by a single NULL character and the list will be terminated with two NULL characters.

Basic Structure

Important Files
[SYSTEM]/OpenAL32.dll <-- "router" OpenAL library
[SYSTEM]/wrap_oal.dll <-- "wrapper" OpenAL library
[SYSTEM]/ct_oal.dll <-- "native" Creative library
[SYSTEM]/nvopenal.dll <-- "native" NVIDIA library

The "router" DLL is an OpenAL DLL which enumerates and makes available OpenAL implementations in other DLLs. If you run the Creative OpenAL Installer, a DLL called "openal32.dll" will be placed in the system directory -- that DLL is a router DLL.

The "wrapper" DLL is a DLL which wraps other audio APIs. The "wrap_oal.dll" library contains three OpenAL implementations -- DirectSound3D, DirectSound, and MMSYSTEM. Each of these implementations will be enumerated as a separate "device."

You may end up with other "native" OpenAL libraries in your system directory as well. If you have a Creative Audigy or Audigy 2 audio card, there will be a ct_oal.dll library in your system directory (after running the Creative OpenAL installer at least -- up till then this library may have been named "openal32.dll"). If you have an NVIDIA NForce motherboard, you may also have a DLL called "nvopenal.dll" in your system directory. These are "native" implementations which directly access the hardware. With the exception of the NVIDIA library "nvopenal.dll," all native implementations will fit the *oal.dll naming convention.

If your application launches and finds the router DLL in the system directory, then the router will use one of the other implementations. If the application enumerates available devices, then the app will get to choose which one to open. If the application opens the default device (NULL), then the router will choose the "best" one.

The best implementation (for the default device case) is determined as follows --

1) Is there a native implementation available which matches the default output device as reported by Windows? If so, that will be the default device. If not, move to #2...

2) Can we use the DS3D device, or is the reported hardware too lame to use it? If the DS3D device works, it will be the default device. If not, move to #3....

3) Can we use the DS device? If so, it will be the default device. If not (this would normally only happen on Windows NT4), move to #4.

4) MMSYSTEM is the default device.

Search Order

The router DLL looks in the current directory, then the application's directory, and then the system directory in that order. If multiple implementations are found that have the same name, the first implementation found is used.

Application Deployment

There are three ways which I consider the most reasonable:

1) The least complicated...

a) Run the Creative OpenAL Installer in silent mode (with the /s option) along with your installer.
b) Dynamically link with "openal32.dll", which is expected to be found in the system directory, and should find "wrap_oal.dll" as an available implementation, but may find others.

2) A more conservative approach...

a) Run the Creative OpenAL Installer in silent mode (with the /s option) along with your installer.
b) Install a version of "wrap_oal.dll" in your application's directory which was tested by the developer and/or the developer's company.
c) Dynamically link with "openal32.dll", which is expected to be found in the system directory, and will use "wrap_oal.dll" from the application's directory, but will enumerate other implementations if found.

3) A very conservative approach...

a) Install a version of OpenAL under any name in any location you want.
b) Dynamically link with your implementation of OpenAL.
c) Optionally allow the user to tell the app (through an INI file or the interface) to use a system-wide implementation of OpenAL elsewhere.

#1 and #2 are the best for your users, because they get the best device support. #2 and #3 are equally conservative in that they guarantee you that the default will be a version of OpenAL which you tested.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!