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.
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.
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).
Hm, don't forget they're not supported on the Mac yet...
Cas :)
Quote from: Ciardhubh on July 13, 2010, 10:00:04
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.
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.
2.5 should go out no later than Thursday evening, since I'm away from Friday.
Quote from: princec on July 13, 2010, 11:05:09
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).
Quote
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.
See attachment for patches. The zip contains the modified files based on yesterdays SVN source code and .patch files for each of them.
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
patches applied, thanks
Quote from: Matzon on July 14, 2010, 09:25:38
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.