[openal] ALC_SOFT_HRTF proposal (update)

[Chris Robinson]

On 10/02/2015 12:19 PM, Ian Reed wrote:
> 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.

0 would be part of the valid ID list, as it would correspond to the 
first ALC_HRTF_SPECIFIER_SOFT entry. I suppose the first could always be 
"any/default", but that seems weird to me. I think a better option would 
be for -1 to signify default, and/or simply not specifying a 
ALC_HRTF_ID_SOFT attribute.

> 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.

Yeah, I think I agree. But I wouldn't mind hearing others' opinions. The 
actual HRTF selected would be able to be queried afterward, of course.

> 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.

I see. I'm not sure I'd say the 28KB sets are "bad", they'd still get 
you full 3D positioning and everything. 187 positions is still 187 
positions... it's like having about 187 distinct speakers around you, 
with the sound being interpolated between them (its a bit more 
complicated than that, but that's basically how it is here).

But I can understand the desire for a data set that has more discrete 
positions.

> 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?

No, since alsoft.ini/conf files aren't really read from data 
directories. It may seem that way on certain OSs, but particularly in 
Linux, data directories and config directories are different.

> 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?

Perhaps. I know some apps like to allow for user-selectable resource 
packs, and allow them to be changed at runtime. If they want resources 
to include data files OpenAL Soft would use (either now or in the 
future), they might want to change the local data root depending on the 
selected resource files. That also ties into the issue of custom storage/IO.

On top of this, I never envisioned the data files to be app-specific. 
Much like configuration options, anything specific apps would be 
interested in providing would be provided through the API in a standard, 
file-agnostic way (like audio data is).

At the same time, I realize there are apps that don't want to (or can't) 
"install" OpenAL Soft, and just want the lib and any extra data to be 
there with their app so it just works (plus it's unlikely for HRTF data 
input to be standardized any time soon). This led to a compromise that 
it would look in the current directory for external data that would've 
otherwise been installed. Of course, that doesn't account for apps 
wanting to put their data somewhere else. That's not an easy problem to 
solve without exposing implementation details.

> 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.)

That's kind of the problem though. When the data gets loaded is an 
implementation detail... it can happen at any time before it's first 
needed. The OpenAL API doesn't have an initialization function, so 
things get initialized and loaded on an as-needed basis. And the need 
may change as implementations update and change.