[Openal-devel] draft 1.1 spec v1.4 up

[Garin Hiebert]

>  a) Why do we have separate types for ALC at all? What's e.g. the
>  difference between an ALint and an ALCint? IMHO the AL types alone
>  should be enough.

I don't think it's really necessary, but of course we'll keep the same 
setup for 1.1 since that's the way it was for 1.0.

> b) 6.2.1: The context attributes should be explained a little bit,
>  having only a one-liner is not sufficient at all to understand what
>  they are for.

Good point -- I'll take a look at expanding that section.

>  c) 6.2.2: What does alcCreateContext return in case of an error?
>  NULL, I guess, but that's not specified.

I'll make that explicit.

>  d) 6.2.2: Allowing NULL as an attrList for alcCreateContext has a
>  tendency to allow buggy code to proceed without notice. An empty list
>  should only be represented by a pointer to zero, so an
>  ALC_INVALID_VALUE might be more appropriate.

I don't think this can change without creating compatibility issues.

> e) 6.2.5: alcSuspendContext returns void.

added...

>  f) 6.3.3: Requiring alcIsExtensionPresent before an extension can
>  actually be used is a real hack (and probably only caused by buggy
>  implementations in the field). Testing and initializing an extension
>  are fundamentally different issues, and they should be kept separate,
>  otherwise we should rename this to "alcInitializeExtension". :-]
>  Getting an entry point via alcGetProcAddress should be enough to use
>  that entry point. Implementations can easily delay initialization
>  until that call or the first use of that entry point.

I don't have strong feelings on this -- so I'm fine with eliminating 
any comments about the implementation doing initialization of an 
extension when it is requested.  In practice, it may actually be 
convenient for the implementation to do _some_ initialization when the 
IsExtensionPresent call is made, however.  An example is Ogg Vorbis.  
The implementation won't know that it can handle Ogg Vorbis until it 
asks for the appropriate library support, and it might as well keep the 
pointers around for later use once it has asked...  Of course, that 
isn't required -- as you point out, the implementation can do all this 
on first use of the extension.

>  g) 6.3.3: Specifying upper case as the canonical extension name seems
>  odd. What's wrong with mixed upper/lower case? IIRC, glXGetProcAddress
>  *is* case sensitive, and we try to mirror common OpenGL behaviour.

I don't really care.  The problem is that we have had some done in all 
uppers and some with mixed case over time.  I decided to try to make 
things simple by just saying that extension queries for 1.1 are 
case-insensitive and declaring everything as all-upper-case in the 
spec.  I only did that because I think it looks better, that's all.  If 
a specific programmer is more comfortable with mixed-case, it would 
still work fine.

> h) 6.3.3: Why is a NULL extName not an error? Again, this has a
>  tendency to hide programming errors.

I suppose we could make at an INVALID_NAME error.  I don't think that 
would cause any problems, and would reflect that an unusable name was 
passed in.

Another thing I need to re-check -- I haven't prefixed all the error 
codes with AL_ or ALC_ yet...

> i) 6.3.5: I think the concept of al(c)GetEnumValue is broken and
>  fundamentally different from the OpenGL way of handling this: If
>  al(c)IsExtensionPresent tells me that an extension is actually
>  supported, why should I bother to query the corresponding token
>  values? Having a central registry for the token values (just like
>  OpenGL does) is the right way IMHO. Keep it simple! Furthermore, it
>  complicates the task for non-C language bindings for OpenAL.

That's the way things are normally done as far as I know.  But if you 
don't have a header or want to make one which contains the codes, then 
al(c)GetEnumValue allows you to get them.  There is a central registry 
on the OpenAL site (which I think is pretty much current).

> j) 6.3.5: If al(c)GetEnumValue stays in the spec, it should at least
>  return an AL(C)enum, not a uint.

That seems to make sense.

> k) 6.3.6: I guess that the ALC error flag should be set to
>  ALC_NO_ERROR after a call to alcGetError.

Yep.

>  l) 6.3.6: OpenGL allows for distributed implementations and therefore
>  allows multiple error flags. Shouldn't we allow this, too?

Seeking feedback from others on this one... I can't say I have thought 
through the implications.

>  m) 6.3.7: It might be clearer to say that the deviceHandle is ignored
>  for an ALC_DEFAULT_DEVICE_SPECIFIER query than to say that NULL is
>  allowed.

I'll try to reword that without putting anyone in a position where they 
might put the wrong value in there...

> The remarks about extensions hold for appendix 7, too. Furthermore,
> 7.1 shouldn't mention alcGetProcAddress.

Yep.



Thanks for all the input...

Garin