[Openal-devel] investigating different define values among the implementations

[Garin Hiebert]

First, a note on AL_FORMAT_VORBIS_EXT --

I was wrong in my earlier post that the Windows beta is the only version
with an inconsistent value for this define.  It turns out that the MacOS
and Windows headers are the same, but different from the Linux
implementation.  So, I'll set this issue aside for a moment and comment on
the "big picture" with regard to these define values...

Second, I re-introduced myself to gawk and came up with the following
tables showing the define-value related differences between
implementations (in our public CVS).  These are (with one exception) only
comparisons between values for defines which exist for all implementations
-- I didn't list obvious implementation-specific defines.

Same value, different name:

Linux -- AL_ILLEGAL_ENUM	0xA002
---
Win/Mac -- AL_INVALID_ENUM	0xA002


Different ENUM values, AL:
				Linux		Windows/MacOS
				------		-------------
AL_PENDING			0x1017		0x2011
AL_PROCESSED			0x1018		0x2012

AL_FORMAT_VORBIS_EXT            0x10003         0x1110


Different ENUM values, ALC:

				Linux		Windows/MacOS
				------		-------------
ALC_ALL_ATTRIBUTES		0x306		0x1003
ALC_ATTRIBUTES_SIZE		0x305		0x1002
ALC_DEFAULT_DEVICE_SPECIFIER	0x300		0x1004
ALC_DEVICE_SPECIFIER		0x301		0x1005
ALC_EXTENSIONS			0x302		0x1006
ALC_FREQUENCY			0x100		0x1007
ALC_INVALID			0		(-1)
ALC_INVALID_CONTEXT		0x201		0xA002
ALC_INVALID_DEVICE		0x200		0xA001
ALC_INVALID_ENUM		0x202		0xA003
ALC_INVALID_VALUE		0x203		0xA004
ALC_MAJOR_VERSION		0x303		0x1000
ALC_MINOR_VERSION		0x304		0x1001
ALC_OUT_OF_MEMORY		0x204		0xA005
ALC_REFRESH			0x101		0x1008
ALC_SYNC			0x102		0x1009


As it worked out, things match up pretty well on the AL front, and not at
all on ALC.  My inclination would be to change the Mac and Windows side
for AL_FORMAT_VORBIS_EXT and the Linux side for everything else. 
AL_INVALID_ENUM seems to be the preferred error over AL_ILLEGAL_ENUM
according to the spec -- a minor change on the Linux side.  Obviously
that's a little lame for me to volunteer Ryan and expecially Joe for more
work and testing, so I await further comment...




Garin