Hello Guest

A few minor OpenAL bugs

  • 11 Replies
  • 13624 Views
A few minor OpenAL bugs
« on: June 06, 2010, 07:30:14 »
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.
« Last Edit: June 06, 2010, 07:40:15 by Ciardhubh »

Re: A few minor OpenAL bugs
« Reply #1 on: June 07, 2010, 11:59:19 »
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.

Re: A few minor OpenAL bugs
« Reply #2 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?

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).

*

Offline princec

  • *****
  • 1933
    • Puppygames
Re: A few minor OpenAL bugs
« Reply #3 on: July 13, 2010, 11:05:09 »
Hm, don't forget they're not supported on the Mac yet...

Cas :)

*

Offline kappa

  • *****
  • 1319
Re: A few minor OpenAL bugs
« Reply #4 on: July 13, 2010, 11:24: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.

*

Offline Matzon

  • *****
  • 2242
Re: A few minor OpenAL bugs
« Reply #5 on: July 13, 2010, 12:06:50 »
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.

*

Offline Matzon

  • *****
  • 2242
Re: A few minor OpenAL bugs
« Reply #6 on: July 13, 2010, 12:07:53 »
2.5 should go out no later than Thursday evening, since I'm away from Friday.

Re: A few minor OpenAL bugs
« Reply #7 on: July 13, 2010, 12:15:18 »
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.

Re: A few minor OpenAL bugs
« Reply #8 on: July 14, 2010, 08:04:14 »
See attachment for patches. The zip contains the modified files based on yesterdays SVN source code and .patch files for each of them.

*

Offline Matzon

  • *****
  • 2242
Re: A few minor OpenAL bugs
« Reply #9 on: July 14, 2010, 09:25:38 »
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

*

Offline Matzon

  • *****
  • 2242
Re: A few minor OpenAL bugs
« Reply #10 on: July 14, 2010, 13:12:37 »
patches applied, thanks

Re: A few minor OpenAL bugs
« Reply #11 on: July 14, 2010, 13:26:09 »
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.