The below communication is from another similar case. Perhaps it suits this case too.
Hope to hear good news from you soon.

By examining the error log you shared, I suspect your system is using the JACK audio server, and a PulseAudio conflict prevents the soundcard form being correctly initialized. Combining PulseAudio and JACK, on the same machine can be, indeed, problematic. If this is what crashes Oolite, you could try the following at a command line:
$ pasuspender -- oolite
(if Oolite installation was not performed with root privileges, then replace "oolite" using the full filepath filename, e.g. ~/GNUstep/Applications/Oolite/oolite).

FYI "pasuspender" is a tool that can be used to tell a local PulseAudio sound server to temporarily suspend access to your soundacrd, to allow other applications (such as JACK) access the soundcard directly. "Temporarily" means, as long as Oolite is running; when Oolite exits, PulseAudio resumes access to the soundcard again.

If this does not resolve the case, then the next suspect could be some kind of incompatibility of Oolite libraries with your system. The usual suspects (in order of probability) on that matter are:
Oolite/oolite-deps/lib/libespeak.so.1
Oolite/oolite-deps/lib/libopenal.so.1
Oolite/oolite-deps/lib/libportaudio.so.2
Oolite/oolite-deps/lib/libSDL-1.2.so.0
and are located in the Oolite/oolite-deps/lib/ folder.
You could check probable incompatibility by "hiding" some of these libraries, forcing Oolite to use your system's libraries.
Example:
$ mv ~/GNUstep/Applications/Oolite/oolite-deps/lib/libespeak.so.1 ~/GNUstep/Applications/Oolite/oolite-deps/lib/libespeak.so.1.oolite
or (if Oolite was installed by root privileges)
$ sudo mv /opt/Oolite/oolite-deps/lib/libopenal.so.1 /opt/Oolite/oolite-deps/lib/libopenal.so.1.oolite

Each time you "hide" a library, execute Oolite and check if the problem persists.