<div dir="ltr">Hi guys,<div><br></div><div>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.</div><div><br></div><div>I guess I'll just stick to reading ALSOFT_CONF & friends with fallback to 7.1, then, leaving the downmix up to OpenAL.</div><div><br></div><div>Regards,</div><div><br></div><div>Leszek</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-05 12:34 GMT+02:00 Chris Robinson <span dir="ltr"><<a href="mailto:chris.kcat@gmail.com" target="_blank">chris.kcat@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/04/2014 11:03 AM, Peter Mulholland wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/10/2014 17:23, Chris Robinson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I mean on the app side. Yeah, if OpenAL says 6.1 is used, and the app<br>
provides 5.1 instead, it will<br>
still work. But as more formats are added, OpenAL could return format<br>
like AL_FORMAT_BFORMAT3D_16<br>
that an aged app has no way to even begin to understand. Obviously, a<br>
properly written app would go<br>
"I don't know what this is, I'll just use some fallback," but if<br>
there's one thing I know about<br>
commercial apps, "properly written" is more the exception than the rule.<br>
</blockquote>
<br>
Isn't that exactly what will happen if you try to create an alBuffer<br>
with a bad buffer type ? I don't see the difference here. The app will<br>
create buffer types it knows about.<br>
</blockquote>
<br></span>
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.<br>
<br>
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<br>
<br>
channels = custom<br>
channel_0 = side-left,   -90, 0<br>
channel_1 = side-right,  +90, 0<br>
channel_2 = front-center,  0, 0<br>
channel_3 = back-center, 180, 0<br>
channel_4 = aux,           0, 180<br>
channel_5 = lfe<br>
<br>
what would it report?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any well written app should be dealing with this query by a switch/case<br>
operation, with "default" catching any format it doesnt know about. In<br>
the case of it not understanding the output format, it should pick a<br>
sensible one. If it cant do that, it should fail.<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you want to mitigate this problem, you could do so by reading<br>
.alsoftrc from a program's working dir in addition to the other places.<br>
This would then mean, if a program proves to have a bug with newer<br>
output formats, it could be explicitly configured into using an older,<br>
compatible one.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
# Force HRTF off for app_name. Other options in [general] will<br>
# still apply.<br>
[app_name/general]<br>
hrtf = off<br>
<br>
The problem here is detecting the name of the app. The executable name alone is not always a good indicator.<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
openal mailing list<br>
<a href="mailto:openal@openal.org" target="_blank">openal@openal.org</a><br>
<a href="http://openal.org/mailman/listinfo/openal" target="_blank">http://openal.org/mailman/<u></u>listinfo/openal</a><br>
</div></div></blockquote></div><br></div>