[openal] Loading of HRTF file fails
djfranken at gmx.de
Wed Feb 19 02:49:02 EST 2014
Ah thank you, it worked! My mistake was to include quotation marks,
since the hrtf tutorial on bitoutsidethebox had those. I've tried the
resample option on one mhr file and it seems to work great too! This is
truly amazing news for VR developers for the oculus rift, where
headtracking and a slight "tilt of the head" improves the value of hrtf
Sorry but now I have to bother you with a few more questions:
I haven't found any license or copyright info on the source site of
those hrtf sample data, are they free to use?
Does OpenAL-Soft support convolution filters?
I checked out Web Audio and it's amazing what they do with those in the
demos. In your browser! :o You simply "download" a recorded effect
instead of using a proprietary algorithm.
As I've hinted before, I'd love to help make a config utility to test
different hrtf and make setup easier. I've noticed that when you shut
down OpenAL and start it again, it reloads the hrtf and I think the
config too. This could be used as a trick to switch hrtf without exiting
the program, then no extension would be strictly needed for hrtf
selection. I'll try that later. First I have to wrangle QT to do my
bidding, I haven't coded in c/c++ for years.
On 19.02.2014 02:01, Chris Robinson wrote:
> On 02/18/2014 08:12 AM, Dennis Franken wrote:
>> My problem is that I seem to be unable to load the mhr files that
>> makehrtf.exe spits out. When running openal-info32.exe I get the error
>> "AL lib: (EE) LoadHrtf: Could not open "oalsoft_IRC_1005_hrtf_44100.mhr"
>> I added these lines to alsoft.ini:
>> hrtf = true
>> hrtf_tables = "oalsoft_IRC_1005_hrtf_44100.mhr"
>> The ini file is read and parsed. I've copied the mhr files into
>> %APPDATA% and also tried copying them into the application directory and
>> even Windows\System32. Looking at the source, it seems that after
>> whatever is done to the poor filename "fopen" fails.
> Hello! :)
> Currently the filename should be an absolute path, and can't contain
> environment variables like %AppData% or $HOME. Otherwise it tries to
> open the given filename relative to wherever the app is run (the current
> working directory at the time of the fopen call). This will likely
> change, though, and work relative to some path (the XDG data paths in
> Linux, probably %AppData% on Windows), or allow environment variables...
> or both. Absolute paths will, of course, always work.
> It's cool that you managed to convert a bunch more HRTF profiles. I'd
> actually like to be able to include more with OpenAL Soft (as optional
> external files in the archive download) to make it easier to select
> different ones. Once I get OpenAL Soft to load them from appropriate
> data paths, anyway. I may even make the current MIT-based set external
> then too, to decrease the size of the dll/so.
More information about the openal