[openal] Querying speaker configuration
lg at inequation.org
Sun Oct 5 16:29:50 EDT 2014
Here's the thing – I have a similar use case to Peter. Namely, a game I'm
porting is using a customized version of FMOD, and since it already has an
OpenAL backend, I decided to go with it. However, FMOD only creates one
output source if it can help it (otherwise it creates a bunch 3D-localized
mono sources in a configuration resembling the given speaker arrangement),
and the kind of source it creates depends on the number of speakers queried
from the "control panel" (as per Windows parlance, i.e. the system-wide
speaker setup). I don't see a sensible way of overcoming this without
either ripping half of FMOD apart, or the game itself (it's quite deeply
integrated). Neither of the latter is an option.
I guess I'll just stick to reading ALSOFT_CONF & friends with fallback to
7.1, then, leaving the downmix up to OpenAL.
2014-10-05 12:34 GMT+02:00 Chris Robinson <chris.kcat at gmail.com>:
> 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
> 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,
> # Force HRTF off for app_name. Other options in [general] will
> # still apply.
> hrtf = off
> The problem here is detecting the name of the app. The executable name
> alone is not always a good indicator.
> openal mailing list
> openal at openal.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openal