[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