[Openal-devel] OpenAL Soft 1.2.218 released
chris.kcat at gmail.com
Tue Jan 29 01:36:54 PST 2008
On Monday 28 January 2008 08:56:32 am Jason Daly wrote:
> I'd just say go ahead and write up the extension first. If Creative is
> interested, they may weigh in. Some of the research folks at Creative
> have shared their wisdom on related topics in the past, but it's much
> easier to do so when you're discussing something concrete (or at least
> the mold that will eventually contain the concrete :-) ).
Perhaps. Though, I guess there are other extensions I'd like to get down
For instance, being able to hint at a requested output format, and
subsequently, tell what the output format is. Something such as (to
shamelessly borrow the extension template):
This extension provides a context attribute hint for setting a
requested output format, and provides a list of recognized output
formats. If the given format cannot be used, the implementation is
free to select another; either an implementation default, or something
close to the requested format.
Q: Should the format be specified as seperate bits-per-sample and
channel count attributes, or a single attribute using specific
A: While two seperate attributes for the bit size and channel count
may be more intuitive, it may actually be more confusing in the
long run. For instance, if setting a 6-channel mode there's no way
to say whether it should be 6.0 surround sound, or 5.1. Such a
distinction may be important for applications trying to load audio
data that has a center channel audio track. Using specific enums
clears up this ambiguity.
Plus, specific enums is what's used to specify the format for
alBufferData. It's nice to remain consistent.
Q: Then how should we handle output formats that there aren't any
format enums for?
A: Unresolved. Although other extensions may be looked at for more
Q: Should new ALC-specific enums be made, or should the existing AL
format enums be used?
A: I don't forsee an issue using the same values as the AL format
enums, as they're only used in specific places, so value clashes
aren't a problem. Additionally, a file with access to ALC will
generally also have access to AL, so there shouldn't be a problem
using those predefined enums. We can make ALC-specific enums in the
future, if needed.
New Procedures and Functions
Additions to Specification
With this extension, an application may specify ALC_FORMATS_SIZE_EXT
to alcGetIntegerv to retrieve a count for the number of recognized
output formats. An application should use the returned value to
allocate an ALCint array large enough for an integer list returned by
ALC_ALL_FORMATS_EXT. Typically, the format list returned by
ALC_ALL_FORMATS_EXT would then be filtered by the application against
known formats, and have the remaining presented as valid output
configurations to the user.
The format values returned by ALC_ALL_FORMATS_EXT will have the same
values as those passed to alBufferData (AL_FORMAT_STEREO16,
AL_FORMAT_MONO8, etc). An implementation must recognize all core
format values, however it is not required to implement them for
output. Extra formats, particularly those specified in the
AL_EXT_MCFORMATS extension, may also be recognized.
An application may also specify ALC_FORMAT_HINT_EXT as a context
creation attribute to hint at a requested output format. It must be
followed by one of the recognized formats returned by
ALC_ALL_FORMATS_EXT. If an unrecognized format is specified, context
creation will fail and generate an ALC_INVALID_VALUE error. After
context creation, regardless of if a format was requested, an
application may query ALC_FORMAT_HINT_EXT to retrieve the output
format set by the implementation for the device.
ALC_INVALID_VALUE is generated if alcCreateContext is called with an
unrecognized format for ALC_FORMAT_HINT_EXT.
ALC_INVALID_VALUE is generated if alcGetIntegerv is called to query
ALC_ALL_FORMATS_EXT and the provided array isn't large enough to store
all the formats.
ALC_INVALID_DEVICE is generated if alcGetIntegerv is called with a
NULL device when querying ALC_FORMATS_SIZE_EXT, ALC_ALL_FORMATS_EXT,
New Implementation State
More information about the Openal-devel