[Openal-devel] OpenAL Soft 1.2.218 released

[Jason Daly]

Chris Robinson wrote:
> 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.
>   

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.


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

Yeah...


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

Either way, it's just that it's not specified at all now.  You don't 
say, for example, what happens if you specify a format that's 
recognized, but unsupported, at context creation.  Does it fall back to 
the closest available format, or does it fail altogether?  (maybe I'm 
just missing this)


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

No, that part makes sense.  I'd keep it this way.


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

That makes sense.


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

No, I like being able to query available formats.  My main concern is 
what happens when you pick a recognized, but unsupported format.


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

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.

I guess the "HINT" part makes sense in this regard.

-- 

--"J"

"I'm a castaway stranded in a desolate land,
 I can see the footprints in the virtual sand."
	--Neil Peart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal-devel/attachments/20080207/8515dbf9/attachment.html