[Openal-devel] OpenAL Soft 1.2.218 released

[Chris Robinson]

On Thursday 07 February 2008 04:04:48 pm Jason Daly wrote:
> I believe AL_EXT_MCFORMATS was intended for input buffer formats, not so
> much for output.  If you load a multi-channel buffer (even just a stereo
> buffer) and play it on a source, no spatialization should be done.  It
> should be played as closely as possible to the original format.  I guess
> this means rechanneling a 5.1 buffer down to a 4.0 output, thought
> you're right, the spec itself is rather thin here.

Right, that's what I mean. If you play a 5.1 format on stereo output, for 
example, what happens to the rear, center, and lfe input data? The original 
code was at a bit of an advantage here since it basically always did stereo 
mixing, then just output to stereo or mono as needed, so it could simply 
re-channel everything to stereo (either at load or while mixing). But when 
you can output to almost anything that you can input, the conversion becomes 
a bit more complex.

As OpenAL is mainly designed for 3d sound, I wouldn't really imagine 
rechanneling multi-channel buffers to be something it would do. If an 
implementation can down-channel, say, quad to stereo when you load it (for 
all intents and purposes), a programmer then couldn't be certain it wouldn't 
down-channel stereo to mono under certain cirumstances.

Granted it's been explained that multi-channel buffers are intended to stay 
multi-channel, but if it can change from one multi-channel configuration to 
another, it seems to be somewhat inconsistant behavior to me.

> Ah, that's what I was missing.  OK, so an app can specify STEREO16, for
> example, and be confident that any compliant implementation will work
> (even if the implementation has to fall back to MONO8 to support it).
> If they want something fancier, then they need to query for it.

Exactly, yeah. Though honestly I think I'm liking the pre-defined format idea 
more. Because there'd be a problem if, for instance, an app asks for 
STEREO16, but instead gets STEREO_FLOAT32, or if the device is forced in 
51CHN16 output. If the app isn't aware of those formats, it wouldn't know how 
to handle it or what to report to the user.

Of course, we can still go with querying the availability of formats, but 
restrict support to core+float32+mcformats so both the app and implementation 
would know the extents of what to expect.