[openal] Enabling HRTF

[Chris Robinson]

On 12/01/2014 04:44 PM, Ian Reed wrote:
> Personally these 3 things are important to me:
> 2. Being able to query OpenALSoft to determine if HRTF is currently
> being used or not.

You would be able to query the device with alcGetIntegerv afterward to 
see what state it's in.

ALCint hrtfenabled = ALC_FALSE;
alcGetIntegerv(device, ALC_HRTF_SOFT, 1, &hrtfenabled);
if(hrtfenabled)
     ...HRTF is in use...

This would also be affected by anything else that may try to enable 
HRTF, like a config option or headphones being detected.

> 3. A non-intrusive way of providing HRTF files for OpenALSoft.

By default with 1.16, OpenAL Soft will first look in the current working 
directory for default-<srate>.mhr. So you can provide OpenAL Soft's 
default-44100.mhr and default-48000.mhr files with your exe, then just 
make sure to change the current directory to where those files are 
before setting up the audio.

> I'd like to know if my setting HRTF to true succeeded, or failed due to
> the wrong frequency, missing HRTF files, or non stereo output.

OpenAL in general doesn't really have a mechanism for providing detailed 
warnings or errors. OpenAL Soft will log an error to stderr if it 
couldn't set up HRTF when requested, including via user config, but 
that's not really something you can read from the app.

Though what you can do is, if HRTF didn't enable even though you 
requested it, check that the .mhr files you provided exist, and that the 
device's ALC_FREQUENCY attribute matches one of your provided files' 
sample rate. If they don't check out, it's the possible reason. If they 
do, it could be the device can't handle stereo output.

> 2. Off hand I feel like this could go either way and you probably know
> better than me.
> If toggling HRTF fails then it would be nice to find out why so I can
> tell the user or choose to call alcDeviceReset with some new options
> that might work better.

As it is currently, trying to enable HRTF will also try to set an 
HRTF-compatible format on the device. If setting HRTF fails, there's not 
really anything more an app can do to make it work.

> Even in the case where OpenALSoft attempts to change sample rate and
> output itself it could still fail due to a missing HRTF file, so
> reporting errors always seems important.

OpenAL Soft does report errors, but only to stderr (by default; a user 
can redirect it by setting ALSOFT_LOGFILE before running the app). For 
development purposes, something like GL_ARB_debug_output could be added, 
but that's not really for capturing error messages to show to users. 
It's intended as developer information to let them know about problems 
in their code, and shouldn't be used in release builds.