OpenAL Soft is a software implementation of the OpenAL 3D audio API. It provides capabilities for playing audio in a virtual 3d environment. Distance attenuation, doppler shift, and directional sound emitters are among the features handled by the API.
Project Admins:
I recently built both static & dynamic libraries from these sources. No problem with dynamic, but the static lib (libopenal.a) does not seem to produce a valid executable on my ubuntu system even though there are no link errors. Any hints or suggestions would be appreciated. fastrgv@gmail.com
On 07/16/2014 04:28 PM, fastrgv wrote:
What's the problem when you try to run the app? How did you build OpenAL
Soft, and your app?
I downloaded the latest (1.15.1) on 15jul14 and built as usual. Did not
get static lib so in another build directory, after changing CMakeLists.txt
line 81 to
SET(LIBTYPE STATIC)
I went thru same process and got libopenal.a and manually put all libs into
/usr/local/lib/OpenAL/.
So, for my app, here is the build script:
g++ $1.cc -o $1 \ lodepng.cpp \ shader.cpp \ text2d.cpp \ loadpng.cpp \ -DSFML_STATIC \ -fpermissive \ -W -Wall -Wextra -pedantic -Wno-unused-variable \ -Wno-literal-suffix \ -std=c++11 \ -I. \ -I/usr/local/include/SDL2 \ -I/usr/local/include \ -I/usr/include/X11 \ -I/usr/include/X11/extensions \ -I/usr/include/GL \ -L/usr/lib/x86_64-linux-gnu \ -lGL -lGLU \ /usr/lib/x86_64-linux-gnu/libsfml-audio-s.a \ /usr/lib/x86_64-linux-gnu/libsfml-system-s.a \ /usr/local/lib/OpenAL/libopenal.so \ /usr/lib/x86_64-linux-gnu/libsndfile.a \ /usr/lib/x86_64-linux-gnu/libvorbis.a \ /usr/lib/x86_64-linux-gnu/libvorbisenc.a \ /usr/lib/x86_64-linux-gnu/libogg.a \ /usr/lib/x86_64-linux-gnu/libFLAC.a \ /usr/local/lib/libSDL2.a -ldl \ /usr/local/lib/libGLEW.a \ /usr/local/lib/libGLEWmx.a \ -pthread
=========================================================
The above script works fine. But when I replace one line with:
/usr/local/lib/OpenAL/libopenal.a \ ( I replaced ".so" with ".a") the build succeeds with no errors, but the executable simply hangs...and I have to ^c to kill the command.
I suppose there are system diagnostics possible but I'm not very good at that kind of thing.
This is on ubuntu 14.04 and I had months ago downloaded thru the system the approved ubuntu version of openal-dev and I noticed it had no static lib which makes me suspicious.
Rod fastrgv@gmail.com
On Wed, Jul 16, 2014 at 5:37 PM, Chris chris-kcat@users.sf.net wrote:
Last edit: fastrgv 2014-07-18
I downloaded the latest (1.15.1) on 15jul14 and built as usual. Went into the build directory and typed "cmake .." followed by "make".
That did not produce a static lib so in another build directory, after changing CMakeLists.txt line 81 to
SET(LIBTYPE STATIC)
I went thru same process and got libopenal.a and manually put all libs into /usr/local/lib/OpenAL/. The openal build seemed to go smoothly.
So, for my app, here is the build script:
g++ $1.cc -o $1 \ lodepng.cpp \ shader.cpp \ text2d.cpp \ loadpng.cpp \ -DSFML_STATIC \ -fpermissive \ -W -Wall -Wextra -pedantic -Wno-unused-variable \ -Wno-literal-suffix \ -std=c++11 \ -I. \ -I/usr/local/include/SDL2 \ -I/usr/local/include \ -I/usr/include/X11 \ -I/usr/include/X11/extensions \ -I/usr/include/GL \ -L/usr/lib/x86_64-linux-gnu \ -lGL -lGLU \ /usr/lib/x86_64-linux-gnu/libsfml-audio-s.a \ /usr/lib/x86_64-linux-gnu/libsfml-system-s.a \ /usr/local/lib/OpenAL/libopenal.so \ /usr/lib/x86_64-linux-gnu/libsndfile.a \ /usr/lib/x86_64-linux-gnu/libvorbis.a \ /usr/lib/x86_64-linux-gnu/libvorbisenc.a \ /usr/lib/x86_64-linux-gnu/libogg.a \ /usr/lib/x86_64-linux-gnu/libFLAC.a \ /usr/local/lib/libSDL2.a -ldl \ /usr/local/lib/libGLEW.a \ /usr/local/lib/libGLEWmx.a \ -pthread
The above script works fine. But when I replace one line with:
/usr/local/lib/OpenAL/libopenal.a \ ( I replaced ".so" with ".a") the build also succeeds with no errors, but the command line executable simply hangs...and I have to ^c to kill it.
I suppose there are system diagnostics possible but I'm not very good at that kind of thing.
This is on ubuntu 14.04 and I had months ago downloaded thru the system the approved ubuntu version of openal-dev and I noticed it had no static lib which makes me suspicious.
I am building (free) games and I'd like to maximize portability by not forcing the end users to install a bunch of libraries that they might not normally have on their system. EG, not many have GLEW installed.
Sorry for the duplicate responses (in case my gmail response worked also) but this one is slightly more complete.
Rod fastrgv@gmail.com
Last edit: fastrgv 2014-07-18
On 07/16/2014 07:10 PM, fastrgv wrote:
Hmm, do you know how to use gdb to get a backtrace? Run gdb with your
app from the terminal:
$ gdb ./myapp
Then at the gdb prompt, run the app:
(gdb) run
When the program hangs, press ctrl-c to cause a SIGINT and drop back to
a gdb prompt. Then you can do this to get a backtrace on all threads:
(gdb) thread apply all backtrace
There could be quite a bit of output depending on how many threads are
currently running on the app, but it would be good to have them in case
the main thread isn't the culprit.
Generally speaking, it's not recommended to use OpenAL as a static lib.
Like OpenGL, users could have different implementations for their
system. This isn't as much of an issue on Linux where there aren't any
hardware-specific OpenAL drivers, but it's still a good idea to leave
OpenAL as a dynamic lib so users can easily update to newer versions
that may have more features, better performance, or just generally work
better.
You can, of course, still provide a version of the dynamic libs you use
if you don't want to require the end user to install any prerequisites.
You can do this easily using the linker's $ORIGIN rpath feature.
https://www.technovelty.org/linux/exploring-origin.html
Essentially, if your app is in /some/path (such that the executable is
/some/path/myapp), you can use the $ORIGIN rpath to make the app look in
/some/path (or some place relative to it) for dynamic libraries at
run-time. If you then move myapp to /some/other/path, it will then look
relative to /some/other/path automatically.
It's as simple as adding -Wl,-rpath='$$ORIGIN' to the Makefile's link
command (the double $$ is so make passes $ORIGIN to the command line,
otherwise it would try to expand an ORIGIN variable, and the '' quotes
so the shell won't expand it either) and placing libopenal.so.1 with the
executable. Alternatively, you can do -Wl,-rpath='$$ORIGIN/lib' and have
your program's hierarchy like this:
./myapp (the executable)
./lib/libopenal.so.1
./lib/libSomethingElse.so.0
etc
Then so long as myapp and the lib folder stay relative to each other,
it'll pick up the dynamic lib there. Just make sure libopenal.so.1 is
the actual lib, not a symlink (or if it is a symlink, make sure it's
pointing to the actual lib which is provided too).
Thanks, Chris. That will gives me all kinds of alternatives and I'm
certain one or more will work for me.
Incidentally, check out "RufasGate" and "RufasCube", which are 2 of my
games on sourceforge.
Rod
On Wed, Jul 16, 2014 at 8:57 PM, Chris chris-kcat@users.sf.net wrote:
Can OpenAL-Soft DLL be modified so that to be accepted by the ALChemy's DSOUND.DLL ?
(needed to use HRTF on win7 64+ which has low-level DSOUND blocked so that Creative had to write its own DSOUND-to-OpenAL converter)
Unfortunately I don't know what ALChecmy checks to determine if an OpenAL device is usable, so I don't know what OpenAL Soft would need to do to make it work.
As an alternative, I have a similar open source project to ALChemy, http://repo.or.cz/w/dsound-openal.git It has some known issues, but it has worked for the few games I've tried.