[openal] ALC_SOFT_HRTF proposal (update)

[Ian Reed]

Sorry I didn't respond to this in a more timely manner.

     Q: It is not unlikely for an implementation to be able to provide 
multiple
        different HRTFs for different purposes (head measurements, quality,
        etc). How is this handled?
     A: Currently, it isn't. An app simply requests HRTF and the 
implementation
        is responsible for picking one if multiple are available. The 
idea of
        enumerating and selecting from all available HRTFs was 
considered, but
        no design has yet been made.

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.
This lets me store them wherever I want in my folder structure and makes 
me responsible for presenting the list of options to the user.
As a second option, letting me provide an array of bytes or similar is 
also nice since I then have ultimate control over where the file comes 
from instead of needing it to be stored on disk.
That said, having the files stored on disk is a pretty common use case.

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.

This actually isn't a big deal in 1.16 since I still have to ensure 
%AppData%\alsoft.ini has HRTF = true, but since the new HRTF extension 
solves most of my issues, I wanted to ensure it also solved this issue.
It would not help much if I can control HRTF from within my app, but 
still have to place the HRTF files in the %AppData% folder.

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.
Though I suppose I could change the working directory to a sub folder 
when enabling HRTF, then change back afterward, but that feels clunky.

I have not tried building from git, perhaps this is already fixed, or 
perhaps I'm doing something else wrong.

Thanks for your time,
Ian Reed


On 7/6/2015 1:57 PM, Chris Robinson wrote:
> Here's an update for the ALC_SOFT_HRTF extension proposal. The change 
> is that {ALC_HRTF_SOFT,ALC_FALSE} explicitly requests no HRTF now, 
> while {ALC_HRTF_SOFT,ALC_DONT_CARE_SOFT} is default behavior 
> (autodetect). Current Git has been updated to reflect this. The 
> alcGetIntegerv query for ALC_HRTF_SOFT will still only return ALC_TRUE 
> or ALC_FALSE, though.
>
> As always, feedback is welcome!
>
>
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20151001/f0dcfc9d/attachment.html>