[Openal-devel] OpenAL Soft 1.2.218 released

[Chris Robinson]

On Thursday 07 February 2008 11:23:28 am Jason Daly wrote:
> Seems reasonable to me.  It's a good step toward supporting explicit
> multichannel formats.  I imagine you've already got usages lined up for
> this in OpenAL-Soft, right?

Yeah. Being able to specify which output channels to map a mono source to was 
something that was brought up (eg. playing an mono voice track on the center 
speaker, or a deep rumbling on the LFE channel). Since OpenAL-Soft doesn't do 
rechanneling, you couldn't just map a source to one of those channels and 
expect it to always work.. you'd have to know if the channel was available, 
and map it to center or front-left/front-right accordingly.

However I may need to rethink that, since this comment by Daniel Peacock: "You 
should hear all the channels of 4.0, 5.1, 6.1 & 7.1 Buffers - but downmixed 
to a stereo output." implies OpenAL should rechannel. I wouldn't really have 
figured it was OpenAL's place to rechannel, and the AL_EXT_MCFORMATS, 
erm- "spec" doesn't mention that, so.. I'm not quite sure how it should all 
work.

But even still, having a way to specify an output format would be useful. 
Games seem to like having a speaker config option, and having a specified way 
to do it without having to be driver-specific would be nice.

> I'm not convinced of the need to have separate ALC_FORMAT_HINT_EXT and
> ALC_FORMAT_EXT tokens for creation and query.  If you query the
> available formats and use one of them, it's not really a hint, because
> its already being supported.

Supported by the driver and by the device may be two different things. For 
something like OpenAL Soft, it can internally handle up to 7.1. But that's 
not saying a given output backend/device can. There may also be resource 
limitations, like if there's not enough hardware voices available at the 
time, or if a user has an output format specified in .alsoftrc or something.

To note though, the original version of the spec didn't have ALC_FORMAT_EXT. 
ALC_FORMAT_HINT_EXT was used for both the context creation attribute and the 
query attribute.. but the 'hint' enum didn't make much sense as a query 
attribute. And I wasn't sure ALC_FORMAT_EXT properly conveyed that the 
context attribute was only a hint (the AL spec is pretty rigid on the other 
attributes). I suppose we can just drop the ALC_FORMAT_HINT_EXT enum in favor 
of ALC_FORMAT_EXT for both, but still specify that the context creation 
attribute is only a hint.

> On the other hand, if you don't query first and just specify a format,
> if it's supported, it will be used.  If it's not supported, context
> creation fails.

I guess specifying an unknown format could cause an implementation to just 
pick a default. But my thinking was if an implementation wanted to pick 
something close, and it got something it didn't recognize, it couldn't 
determine what's "close". Plus, IMO, an app should make sure it's passing a 
valid format instead of a junk value.

> The only gray area I see is that all core formats have to be recognized,
> but not supported.  It's not really clear what happens when you specify
> a recognized format at context creation, but the implementation doesn't
> support it (this may be where the "hint" element comes in).  You might
> want to clarify this in the spec.

I figured if all core format had to be recognized, an app would have a nice 
safety cusion that it would always have something to specify to the 
implementation/show to a user, in case an implementation only supported 
esoteric formats the app didn't know about, while still allowing an 
implementation to support more formats without requiring new extensions every 
time a new one pops up.

If you don't think requiring a new extension for more formats is a big problem 
though, how about instead of leaving it up to the app, we could just specify 
that an implementation must recognize the core formats plus those in 
AL_EXT_float32 and AL_EXT_MCFORMATS? Then drop the whole 
querying-available-formats thing, and just allow those for hints.

And it does say "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" in the "Overview" section. I can reiterate and 
clarify that in the "Additions to Specification" section, though.