[openal] Enabling HRTF

[Chris Robinson]

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?