> Will there be some kind
> of "maintenance release" of the 1.1 spec, or some additional annotated
> spec
Sure.
> * Section 6.3.7 (String Query) says:
>
> "Specifying NULL for deviceHandle when asking for ALC_EXTENSIONS will
> generate an ALC_INVALID_DEVICE error."
>
> Error conditions are specific to a device, but the big question is:
> Which one?? The given handle was NULL, so there is nothing to record.
> This is a general issue with ALC_INVALID_DEVICE, and the longer I think
> about it, the more I'm convinced that it is a design error to have ALC
> errors tied to a device, they should simply be global. In any case, my
> proposal would be to nuke ALC_INVALID_DEVICE and e.g. simply return NULL
> for alcGetString and leave the behaviour of alcGetIntegerv undefined in
> a similar case. And if that change is not wanted, some clarification is
> urgently needed here.
I agree that this situation is not ideal, but it couldn't really be addressed
for 1.1. Here's the deal -- if there is no current context, then there is no
implied current device, and no errors can be reported. If there is a current
context, then that context's device is where errors are reported.
What does "current context mean"? It means that alcMakeContextCurrent has
been called, and the last legal call to alcMakeContextCurrent was not
alcMakeContextCurrent(NULL).
Effectively, this means that an OpenAL application can't get proper error
support until an alcOpenDevice and an alcCreateContext call have completed
successfully. After that point, it is possible to manage any number of
contexts with full error handling.
> * alcCaptureCloseDevice should return an ALCboolean for the same reason as
> alcCloseDevice does it now, not void.
Seems sensible -- Any comments, Ryan?
> * ALC_CAPTURE_DEFAULT_DEVICE_SPECIFIER and ALC_CAPTURE_DEVICE_SPECIFIER
> should probably behave like ALC_DEFAULT_DEVICE_SPECIFIER and
> ALC_DEVICE_SPECIFIER, i.e. for the former the device is ignored and the
> latter returns a double-zero-terminated list of strings of available
> capture devices if the device is NULL. If this is meant, it should
> probably be stated more explicitly.
The intent was to treat them the same -- so the spec should be updated in this
regard.
> * What exactly should the size parameter of alcGetIntegerv mean? Bytes or
> ALCints? This is handled inconsistently in the different implementations
> in the OpenAL repository.
ALCints IMHO. If you want to get all the context attributes at the same time,
then this makes it easier -- you just get ALC_ATTRIBUTES_SIZE, and then pass
that value back in as "size" for an ALC_ALL_ATTRIBUTES query.
Obviously the spec should be updated on this.
> * Is the device ignored for ALC_MAJOR_VERSION/ALC_MINOR_VERSION, so that
> e.g. NULL is allowed? This is again handled inconsistenly in the SI.
The spec should be updated on this. I think NULL should be acceptable in this
case, to make enumeration slightly easier.
> * I guess that a NULL device for ALC_CAPTURE_SAMPLES is invalid, but this
> is not stated explicitly.
Once again, the spec should be updated, and I agree that in this case a NULL
device should not be accepted.
> Nothing dramatic, but the devil is in the detail when one really has to use
> the spec for implementing things...
Yep.
Garin
|
