<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Sorry I didn't respond to this in a more timely manner.<br>
<br>
Q: It is not unlikely for an implementation to be able to
provide multiple<br>
different HRTFs for different purposes (head measurements,
quality,<br>
etc). How is this handled?<br>
A: Currently, it isn't. An app simply requests HRTF and the
implementation<br>
is responsible for picking one if multiple are available. The
idea of<br>
enumerating and selecting from all available HRTFs was
considered, but<br>
no design has yet been made.<br>
<br>
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.<br>
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.<br>
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.<br>
That said, having the files stored on disk is a pretty common use
case.<br>
<br>
I am quoting a very old response from Chris:<br>
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. <br>
<br>
My experience is that this does not work.<br>
I am using 1.16 and I have copied both of the mhr files from
%AppData%\openal\hrtf into my application folder.<br>
I also copied them into an hrtf folder in my app folder, and an
openal\hrtf folder in my app folder, just in case.<br>
When I rename %AppData%\openal to something else, HRTF no longer
works.<br>
The %AppData%\alsoft.ini file remains unchanged.<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
Though I suppose I could change the working directory to a sub
folder when enabling HRTF, then change back afterward, but that
feels clunky.<br>
<br>
I have not tried building from git, perhaps this is already fixed,
or perhaps I'm doing something else wrong.<br>
<br>
Thanks for your time,<br>
Ian Reed<br>
<br>
<br>
<div class="moz-cite-prefix">On 7/6/2015 1:57 PM, Chris Robinson
wrote:<br>
</div>
<blockquote cite="mid:559ADDAF.7080001@gmail.com" type="cite">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.
<br>
<br>
As always, feedback is welcome!
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
openal mailing list
<a class="moz-txt-link-abbreviated" href="mailto:openal@openal.org">openal@openal.org</a>
<a class="moz-txt-link-freetext" href="http://openal.org/mailman/listinfo/openal">http://openal.org/mailman/listinfo/openal</a>
</pre>
</blockquote>
<br>
</body>
</html>