[openal] Enabling HRTF

[developer at oldunreal.com]

Great its taken care about this. For now I think its a real mess to only 
find out how to enable it and to put some config file into %appdata% 
without having a chance to check out (or better to log it) if its 
enabled and working or not is kinda annoying, for now I just can rely on 
my ears and I am not really used to hear with headphones.

For me
ALCint attribs[] = { ALC_HRTF_SOFT, enable, 0 };
context = alcCreateContext(device, attribs);

would be already sufficient, however,
void alcDeviceReset(ALCdevice *device, const ALCint *attribs);

this method would be real sexy.

The method described below to get the state would be perfectly fine also.
And to just have the mhr file in the current working directory fits also 
all I need. What license do these mhr files have anyway?

Thanks for working on all this, I plain love this API.

~Jochen

On 12/02/2014 08:11 AM, Chris Robinson wrote:
> 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.
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal