[openal] Querying speaker configuration

[Peter Mulholland]

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.

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.

> I've seen Windows apps that will crash if it receives an unexpected driver /filename/ when querying
> display info. The app doesn't use the driver directly, it uses D3D and checks the driver name to
> enable some card-specific hacks and tweaks, and will crash if it doesn't recognize the driver name.

Stupid programmers do stupid things on any platform.

>
> Ultimately, I'm just concerned about adding queries to the API where the returned information is
> completely system-defined and needs to be interpreted by the app to be useful, especially when
> binary backwards compatibility is all but required.

You could always do this by adding a query that returns AL_FORMAT enums in addition to querying 
AL_FREQUENCY, AL_BITS and AL_CHANNELS I guess.

> Things would certainly be much better if we only had to be concerned about sensible programmers, who
> followed specifications and handled unexpected values logically. Unfortunately, there's many other
> programmers that do dumb things, things that just happen to work for them, and then the code is
> never touched again prior to release.

Stupid programmers will do stupid things, no matter how you try and protect them. There is already 
plenty of scope for this in OpenAL. Let buggy apps worry about being buggy, not openal-soft.

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.

-- 
Regards,

Peter Mulholland
Software Developer & System Administrator
Virtual Programming Ltd

----------------
E: peter.mulholland at vpltd.com
www.vpltd.com

Privileged/Confidential Information may be contained in this Electronic
Message and is intended only for the use of the addressee. It may not be
copied or forwarded without the permission of the sender.