[openal] Querying speaker configuration

Chris Robinson chris.kcat at gmail.com
Sat Oct 4 12:23:50 EDT 2014


On 10/04/2014 08:02 AM, Peter Mulholland wrote:
> So there is no harm in saying what the speaker format is - if it's not
> handled, it will still work.

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.

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.

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.

> I really do not see the harm in adding this information in the same way
> as it is available for a loopback device.

The loopback device is different because you have to specify the format 
first. And when you specify the format, you either get it or the call 
fails, so it will never give you something you didn't ask for. That's 
necessary since OpenAL Soft will be giving you the audio, it would be 
useless if you didn't know how it's formatted.

> It may for example be very
> useful for debug logging, and for those of us who are using it to
> provide premixed streams, we're sensible enough to know to be careful
> with it.

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.


I think the best I could do is to add a query for the best-fit format, 
one that is specifically limited to mono, stereo, quad, 5.1, 6.1, and 
7.1, with a note that the format does not represent the actual output 
configuration. Though I'd like to get other people's opinion on that, if 
possible.


More information about the openal mailing list