[openal] Enabling HRTF

[Ian Reed]

Hi Chris,

First off, I'm really glad you're looking at implementing HRTF togggling.

Personally these 3 things are important to me:
1. Giving users the ability to toggle HRTF in a preferences menu of my 
app without requiring them to restart the app, or me to jump through a 
lot of hoops to tear down and renew all the buffers and sources.
2. Being able to query OpenALSoft to determine if HRTF is currently 
being used or not.
3. A non-intrusive way of providing HRTF files for OpenALSoft.

The second is more than just knowing what HRTF config options I have 
passed to the context.
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.
That way I never tell the user that they are now hearing HRTF when in 
fact they are not.
It's also nice to know if HRTF was enabled by default, assuming the user 
already had appropriate settings in %AppData%.

The third refers to how I can package the OpenALSoft dll in a sub folder 
of my application, but need to alter the shared %AppData% folder to 
provide HRTF files for my app's local copy of the OpenALSoft dll.
My apps are generally just downloaded as zip files and do not include a 
full blown install process, which makes it easy to remove them in their 
entirety or copy them to a thumb drive or new machine.
Needing to change the shared %AppData% folder makes my apps feel a lot 
less self contained.

I'm just throwing these things out in case they can also be solved in 
your changes.

Here are my gut reactions to your 2 questions:
1. Of the 3 options number 1 feels clunky for updating HRTF settings on 
the fly.
Option 2 and 3 look much easier to work with as an app developer.
I haven't been concerned with changing any of the non-HRTF settings in 
my apps, which makes option 2 pretty straight forward.
But if I will need to change sample rate or output settings because HRTF 
fails without doing that then option 3 sounds the best.

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.

The major benefit of finding out why it failed is for my debugging / 
developing and for displaying an error to the user at runtime.
During development I will end up adding logic to detect HRTF files and 
know which sampling rates are supported.
That way I can show the user what needs to be changed before letting 
them toggle HRTF rather than waiting for the device to give me an error.
But no developer is perfect or always has time to check all settings 
before passing them to OpenALSoft, in which case it's nice to know when 
things failed and let the user know as well.
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.

I hope my input was a little helpful.

~ Ian Reed


On 12/1/2014 4:48 PM, Chris Robinson wrote:
> Hello!
>
> This is an issue that's come up and I'm still unsure about the best 
> way to handle it. So I'm looking for input. This is a question for 
> both app developers, and OpenAL implementors.
>
> The question is, what would be the best way to allow an app to request 
> HRTF output, and to what degree should it have control?
>
>
> Currently, OpenAL Soft has a not-yet-complete extension that allows an 
> app to request HRTF for the device when creating the context. This is 
> a simple method, as all you would need to do is
>
> ALCint attribs[] = { ALC_HRTF_SOFT, enable, 0 };
> context = alcCreateContext(device, attribs);
>
> But it makes it a bit quirky if you want to enable or disable it after 
> audio's already been set up. You would either have to destroy the 
> current context (along with all context-specific resources, like 
> sources and auxiliary slots), create a new one with the appropriate 
> attributes, and set everything back up ... or just create a dummy 
> context with the appropriate attributes (causing the device to change 
> if its able), then immediately destroy it without using it. Both ways, 
> while functional, seem kinda sloppy to me.
>
>
> Alternatively, the OpenAL-MOB fork added an extra ALC method,
>
> ALboolean alcDeviceEnableHrtfMOB(ALCdevice *device, ALboolean enable);
>
> However, this feels limiting; it only allows toggling HRTF on or off, 
> with no real way to tell OpenAL to just go with default behavior. 
> Also, it uses a single-purpose function to set a device parameter 
> instead of a general-purpose one.
>
>
> A possible third option is to add a function where you just specify 
> updated attributes for a device. e.g.
>
> void alcDeviceReset(ALCdevice *device, const ALCint *attribs);
>
> This would update a device just like alcCreateContext would, but 
> without creating a new context.
>
>
> Now, given one of those options, the follow-up question is how much 
> priority should this option have? For instance, if the device is 
> normally using 5.1 output, should enabling HRTF in one of these ways 
> try to force stereo output, or should it only use HRTF if output is 
> already stereo? Similarly for the sample rate, if the device would 
> normally use an incompatible rate, or the app specifically requested 
> an ALC_FREQUENCY that can't work with HRTF, should it still try to 
> make HRTF work by changing the sample rate?
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal