[openal] ALC_SOFT_HRTF proposal (update)

[Ian Reed]

Seems like ALC_HRTF_ID_SOFT should have it's own "auto" ID, which is the 
default.
I guess that's why  you said: 0 <= id < count
So 0 is the auto / default.

Chris said: 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.

I think it is not so bad.
Off hand as I think of ways to combine both values into a single 
attribute, the results look bad.

Chris said: One question would be, what if the specified HRTF can't be used?

Off hand my vote goes with using any that works, which is like 
ALC_HRTF_ID_SOFT falling back to the auto / default setting.
Acting as if ALC_HRTF_SOFT was not specified seems wrong to me.

Thanks for the tip on debugging, I'll try that soon.
I definitely have the files in the CWD.

If you included the 28KB data sets in the liv I personally would just 
include the better data sets in my own deployment as separate files, 
making the 28KB sets still unused.
If you included what you considered to be "very good" quality default 
sets then I might use them rather than including extra files.
Not sure what most people would do, but my preference is for better 
quality when people are choosing to use HRTF at all.

All that said, I'm not really an audio expert, I just know I hear a 
difference when HRTF is enabled and I want the positioning of sounds to 
feel as accurate as possible.

Chris said: More generally, being able to specify a "root" directory for 
local data files might be possible as an OpenAL Soft-specific thing

Admittedly I am only concerned with using the OpenALSoft implementation, 
so a solution like this sounds great to me.
But I do realize you have to balance the needs of others and that you 
want to keep in line with the OpenAL standard whenever possible.
Would the alsoft.ini file be found in this local root directory as well?

Chris said: ... 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?).

My use case would only need to set the local root directory once.
Are there valid use cases for changing it several times at runtime?
If so, are they common?
That option is more flexible, but as you say, it is also very tricky.

One option would be to explicitly limit callers to only set the root 
directory once, and before the call to alcCreateContext, (or whenever 
all your data gets loaded.)
By limiting the use of this function you solve 90% of the cases now and 
are free to provide less limiting behavior in the future.
Then if it turns out the more complicated case is actually needed and 
warrants the extra work, you can extend to handle that.
It could even reuse the same function since multiple uses of that 
function are currently not supported.
You would not be breaking backwards compatibility because the case you 
support now is so limiting and future extensions would leave that case 
working the same.
Or in other words, handle the easy case now, in a way that lets you 
safely push the tough decisions off until later.  (Assuming they are 
ever needed at all).



On 10/2/2015 2:43 AM, Chris Robinson wrote:
> 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_SOFT, ALC_TRUE,
>     ALC_HRTF_ID_SOFT, id, /* 0 <= id < count */
>     0
> };
> 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?).
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal