[Openal-devel] OpenAL Soft 1.2.218 released

[Chris Robinson]

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

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


Name

        EXT_format_hint

Name Strings

        ALC_EXT_format_hint

Version

        1.0

Number

        ??

Dependencies

        None

Overview

        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.

Issues

        Q: Should the format be specified as seperate bits-per-sample and
           channel count attributes, or a single attribute using specific
           format enums?
        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
           formats.

        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

        None

New Tokens

        ALC_FORMATS_SIZE_EXT                      0x????
        ALC_ALL_FORMATS_EXT                       0x????
        ALC_FORMAT_HINT_EXT                       0x????

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.

Errors

        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,
        or ALC_FORMAT_HINT_EXT.

New State

        None

New Implementation State

        None