[openal] Querying speaker configuration

Chris Robinson chris.kcat at gmail.com
Sun Oct 5 06:34:31 EDT 2014


On 10/04/2014 11:03 AM, Peter Mulholland wrote:
> On 04/10/2014 17:23, Chris Robinson wrote:
>
>> I mean on the app side. Yeah, if OpenAL says 6.1 is used, and the app
>> provides 5.1 instead, it will
>> still work. But as more formats are added, OpenAL could return format
>> like AL_FORMAT_BFORMAT3D_16
>> that an aged app has no way to even begin to understand. Obviously, a
>> properly written app would go
>> "I don't know what this is, I'll just use some fallback," but if
>> there's one thing I know about
>> commercial apps, "properly written" is more the exception than the rule.
>
> Isn't that exactly what will happen if you try to create an alBuffer
> with a bad buffer type ? I don't see the difference here. The app will
> create buffer types it knows about.

An app creates buffers with formats it knows about. Like with loopback 
devices, the app has to specify the format so it will know what the 
format is. An old app can't specify AL_FORMAT_BFORMAT3D_16 if it doesn't 
know it, for example, or then get confused because OpenAL updated with 
support for AL_EXT_BFORMAT.

It's different with a playback device, because the output format isn't 
dependent on anything the app specifies. An app can be given a device 
format enum without knowing what it is. And speaking of enums, there may 
not even be one to give back; e.g. what would be returned with the 
5.1-side output format? Currently it's an internal value that can change 
at any time between runs. And like I mentioned, eventually OpenAL Soft 
will support completely custom setups, so if the user has something like

channels = custom
channel_0 = side-left,   -90, 0
channel_1 = side-right,  +90, 0
channel_2 = front-center,  0, 0
channel_3 = back-center, 180, 0
channel_4 = aux,           0, 180
channel_5 = lfe

what would it report?

> Any well written app should be dealing with this query by a switch/case
> operation, with "default" catching any format it doesnt know about. In
> the case of it not understanding the output format, it should pick a
> sensible one. If it cant do that, it should fail.

Right, but what it should do and what it does do aren't necessarily the 
same thing. For OpenAL, it's imperative that future versions of the lib 
continue to work with the app.

> If you want to mitigate this problem, you could do so by reading
> .alsoftrc from a program's working dir in addition to the other places.
> This would then mean, if a program proves to have a bug with newer
> output formats, it could be explicitly configured into using an older,
> compatible one.

That's actually part of what ALSOFT_CONF was intended for. A user can 
create a custom config file which contains whatever settings a specific 
app needs, and the app's startup script could be modified (or one could 
be made) to set ALSOFT_CONF to it before launching the executable.

Ideally I'd like to be able to detect the app and automatically apply 
known needed tweaks, and/or allow configuration options to be 
app-specific, e.g.

# Force HRTF off for app_name. Other options in [general] will
# still apply.
[app_name/general]
hrtf = off

The problem here is detecting the name of the app. The executable name 
alone is not always a good indicator.


More information about the openal mailing list