[openal] ALC_SOFT_HRTF proposal (update)

Chris Robinson chris.kcat at gmail.com
Fri Oct 2 04:43:14 EDT 2015

On 10/01/2015 12:23 PM, Ian Reed wrote:
> As an app designer, it would seem easiest if OpenALSoft let me give it a
> file path to the HRTF file, rather than searching for them on its own
> and giving me a list of options.

Problem is that different implementations may expect different formats, 
or not even support user-selectable files. Different versions of the 
same implementation may support different formats too, and the app can't 
know which files will work. Let alone pre-installed HRTFs the app 
doesn't necessarily know to look for.

It wouldn't be too difficult to add a method to get an indexed list of 
HRTFs, something like

ALCint count;
// Also (re)enumerates the available HRTFs
alcGetIntegerv(device, ALC_NUM_HRTF_SPECIFIER_SOFT, 1, &count);

for(i = 0;i < count;++i)
     name = alcGetStringiSOFT(device, ALC_HRTF_SPECIFIER_SOFT, i);
     printf("%d: %s\n", i, name);

ALCint attr[] = {
     ALC_HRTF_ID_SOFT, id, /* 0 <= id < count */
context = alcCreateContext(device, attr);

It feels a bit clunky to have one attribute for on/off/auto, and another 
to select a specific set. But it's probably one of the better options 
for enumerating and selecting from multiple data sets.

One question would be, what if the specified HRTF can't be used? For 
example, if the device refuses to use the sample rate needed by the 
given HRTF, or some other error is encountered during load, or the id is 
out of range. Should it not use HRTF in that case, or should it fall 
back to any that works, or just act as if ALC_HRTF_SOFT and 
ALC_HRTF_ID_SOFT were unspecified?

> I am quoting a very old response from Chris:
> 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.
> My experience is that this does not work.
> I am using 1.16 and I have copied both of the mhr files from
> %AppData%\openal\hrtf into my application folder.
> I also copied them into an hrtf folder in my app folder, and an
> openal\hrtf folder in my app folder, just in case.
> When I rename %AppData%\openal to something else, HRTF no longer works.
> The %AppData%\alsoft.ini file remains unchanged.

You could try to enable traces (set the ALSOFT_LOGLEVEL env var to 3, 
and probably ALSOFT_LOGFILE to an output filename if you don't like it 
going to stderr). With 1.16, that should show what files it failed to 
open. Like mentioned, you need to make sure the process's current 
working directory is set to where those files are (or more simply, make 
sure those files are in the CWD, wherever it is).

> And as mentioned above, it would be nicer if I could tell OpenALSoft
> where to find the HRTF file I want to use, because it lets me store the
> files in a sub folder.

This does touch on the issue of how to provide a default set.

Previously, OpenAL Soft had an HRTF data set compiled into the lib so 
that it would always be available without external files. The problem 
was that it added to the size of the lib even when it wasn't needed. 
Current git builds into a 600~650KB lib in release mode (which seems 
unexpectedly high, actually), and the default mhr files are about 100KB 
combined (one 44.1khz set and one 48khz set, as those are the most 
common output rates), and so would bloat to 700~750KB in release mode. 
For comparison, the 1.15.1 release in my distro has a 360KB lib.

There are alternate sets I could use... one in particular would be about 
28KB for the 44.1khz and 48khz data sets combined, which is far more 
reasonable. These of course have relatively few data points (about 187 
discrete positions, vs the current set's 710), and so aren't as good in 
that regard. Might still be good enough though, given that OpenAL Soft 
bilinearly interpolates between discrete positions to increase the 
apparent precision.

More generally, being able to specify a "root" directory for local data 
files might be possible as an OpenAL Soft-specific thing, but I worry 
about the implications since it can expose internal behavior (i.e. when 
a data file is opened; could be before the call to change it in one 
version and after in another), and leads to questions of how the lib 
should behave if it opened a local data file before the local path is 
changed (should it invalidate the loaded data and reload it ASAP, which 
would be very tricky? or should loaded data just stay loaded?).

More information about the openal mailing list