[Openal-devel] openal-soft

[Chris Robinson]

On Wednesday 06 February 2008 12:00:49 pm Lukasz Pawelczyk wrote:
> Are you and in what aspect at the current state of developing interested
> in bug reports?

I'm always interested in handling problems people have with the lib. :)

> As I'm not very into sound programming I can only 
> provide some very general problems I've run into, but can provide
> everything thats necessary to reproduce them.
> 1. Totally no sound in one old icculus port of a windows game.

Which game? Some extensions have been dropped (particularly those for playing 
MP3 and Vorbis, and the callback extension), so if it relies on them, there 
will be issues. I won't mind adding some of the extensions back, but ones 
like the aforementioned likely won't.

> 2. Only front speakers playing on other game where on old OpenAL rear
> were playing as well (I'm 99% sure rear were just a copy of front ones,
> but still, sound was present).

You can try forcing the default alsa device to a hardware voice (by default it 
uses the 'default' device, which is kinda touchy in what it does). You can 
also try to enable full 4 or 5.1-channel mixing. Using OpenAL Soft 1.2, you 
can create ~/.alsoftrc and add the lines:

[general]
format = AL_FORMAT_QUAD16 # or AL_FORMAT_51CHN16 for 5.1

[alsa]
device = surround40 # or surround51, or hw:0,0 for a hardware voice

Just note that the capitalizations for AL_FORMAT_* and surround* are 
important.

> I dont know if that matters but there is no alext.h in your source package.

I suppose it might be useful to add one, with proper extension guards like 
glext.h typically has. The original alext.h was quite messy and rather 
unuseable, though.

> Also it would be nice to make static version as well during compilation.

Generally speaking, I'm opposed to having a static version of OpenAL. It 
prevents upgrading of the lib, and prevents users from using their own, 
possibly accelerated, version. If it's because you want to have a 
known-working version bundled with an app, the general method is to place it 
in a subdirectory of the executable and add that path to the LD_LIBRARY_PATH 
environment variable in the app's startup script.

So for instance you'd have ./myapp, ./myapp.x86, and ./lib/libopenal.so.1, and 
have ./myapp be a shell script:

#!/bin/sh
export LD_LIBRARY_PATH=./lib:"$LD_LIBRARY_PATH"
./myapp.x86 $@

Then when your app loads OpenAL, it will be the one in the lib subdirectory. 
If a user wants to use a different/their own version, all they need to do is 
rename the provided libopenal.so.1 and it'll then pick the system-installed 
one (and if you want to update it, all you need to do is provide the new AL 
binary, instead of recompiling and redistributing a full executable).


That said, I won't mind listening if you have an argument for static-linking.

> And by all means, please, don't stop developing it. Its really sad to
> see that the library that was made for Linux is in such a bad shape (in
> many cases barely usable) while Creative and Apple happily took it over
> and closed its development.

No plans to stop it yet. :) Although isn't Apple's OpenAL still open source 
(in the SVN repo)? Or is that an old version like the Windows one?