A few minor OpenAL bugs

[Ciardhubh]

While writing a log utility for OpenAL, I ran into a few minor bugs:

• 
  Copy&Paste bug in org\lwjgl\test\openal\OpenALInfo.java:
  line 194 should read: entries = effects.entrySet();
  instead of: entries = filters.entrySet();
• 
  If you call ALC10.alcGetString(AL.getDevice(), ALC10.ALC_DEVICE_SPECIFIER/ALC_CAPTURE_DEVICE_SPECIFIER) (i.e. with a non-null device), the returned String contains the name of the device plus some junk characters. According to the spec, a non-null device results in alcGetString (with ALC_DEVICE_SPECIFIER or ALC_CAPTURE_DEVICE_SPECIFIER) returning the name of the device. However org_lwjgl_openal_ALC10.c#org_lwjgl_openal_ALC10_nalcGetString always searches for a double-null, resulting in extra garbage chars in case there is only one, as the length is miscalculated. If the device is a valid device, this check should only look for the usual single null.
  
• 
  Class ALC11 misses two tokens (ALC_MONO_SOURCES and ALC_STEREO_SOURCES):
  public static final int ALC_MONO_SOURCES = 0x1010;
  public static final int ALC_STEREO_SOURCES = 0x1011;
  

Edit:
Oh by the way, I assume it's intentional or OpenAL Soft is to blame that passing parameters to AL.create(...) is largely ignored? On 32bit Win XP frequency is correctly applied (if > 8000) to the context but refresh (fixed at 43) and sync (always false) is always ignored . On 32bit Linux frequency (48000), refresh (50) and sync (false) are fixed, no matter what you pass as parameters.

[Ciardhubh]

Another minor issue:
AL10.AL_DATA is no longer supported by OpenAL, as far as I understand it. It not in the OpenAL spec, OpenAL soft doesn't define it (and throws an invalid enum error) and this post (http://opensource.creative.com/pipermail/openal/2005-August/008549.html) on the Creative mail-list says it's been removed.

[Ciardhubh]

Since these bugs still exist in the latest build, does anybody mind if I write a patch for LWJGL?

And another thing: there are a lot of OpenAL extensions that are not supported by LWJGL, even though the OpenAL Soft version LWJGL uses supports them, e.g. AL_EXT_MCFORMATS, AL_EXT_MULAW, AL_EXTX_loop_points, etc. If there's an interest I could write extension classes for LWJGL, i.e. for those extensions that are supported by the current OpenAL Soft (most of them are merely a bunch of new constants for formats and other existing functions).

[princec]

Hm, don't forget they're not supported on the Mac yet...

Cas

[kappa]

Since these bugs still exist in the latest build, does anybody mind if I write a patch for LWJGL?

Be great if you could do a patch. LWJGL 2.5 should be out pretty soon so would be nice if it made the release.

But yeh do bear in mind that there is no openal-soft on mac yet.

[Matzon]

fwiw, you can use openal-soft, through a pulse-audio backend on mac. I have the complete binaries for this - but I don't know much more about it. I'd prefer not to distribute the pulse-audio thingy through lwjgl - and instead let it be up to the developer to do so.

[Matzon]

2.5 should go out no later than Thursday evening, since I'm away from Friday.

[Ciardhubh]

Hm, don't forget they're not supported on the Mac yet...

Does that matter much? As with OpenGL, it is the API-user's responsibility to make sure extensions he wants to use are supported by the platform. I have little experience with Macs but I guess these extensions might possibly be supported there, too. Would it hurt to provide support in LWJGL?

I cannot write code for all existing extensions, as I could not test the ones not supported by OpenAL Soft; and the OpenAL extension registry (http://icculus.org/alextreg/index.php) seems to be missing a few. So I thought I'd start there.

Apropos the 2.5 release: if implemented, how would these classes be named, e.g. for AL_EXT_MCFORMATS? Prefixed with EXT as in OpenGL, i.e. EXTMCFormats? If EXT is prefixed, shouldn't the EFX class also be called EXTEFX10 (from ALC_EXT_EFX) to stay consistent? Then again it's kind of a special case (its own version, rather large spec). Just a thought that came to mind when browsing the list of extensions (what with EFX10 not being released yet).

Be great if you could do a patch. LWJGL 2.5 should be out pretty soon so would be nice if it made the release.

I'll try to write the patch for those bugs by tomorrow.

[Ciardhubh]

See attachment for patches. The zip contains the modified files based on yesterdays SVN source code and .patch files for each of them.

[Matzon]

looks great - will apply these later. Will you be working on the extensions too?

I think the naming should follow opengl - but yes, EFX is a bit special

[Matzon]

patches applied, thanks

[Ciardhubh]

Will you be working on the extensions too?

Unless there's a reason not to, I'll start later this week. They won't be ready till tomorrow, though.