steam-audio defaults to built-in HRTF when trying to load custom one

[miccio-dk]

Hi everyone,
On a sample project, we're capable of loading and switching different SOFA HRTF sets in real-time. However, while some 3rd-party SOFA files work just fine, a few custom-made ones fail to be loaded causing steam-audio to silently (no pun intended) fall back to the default HRTF set. No logging or error message is reported, and the only noticeable effect is that the currently-selected custom HRTFs are not used in favor of unity's default set.

The custom HRTF set follows the SimpleFreeFieldHRIR 1.0 convention as well as all the specifications mentioned here, and have been generated using the official MATLAB/Octave APIs. The dimension of the set is 15132128 (MeasurementReceiversNsamples). Here's a link to one of the sets: subj_A.sofa.zip

On issue #123 (which is extremely similar to ours), I saw that @lakulish managed to inspect the underlying h5 data structure and found the issue there.
Could you please verify what could be wrong with the HRTF set or explain how to see that ourselves?
Thanks in advance! :)

[miccio-dk]

For posterity: I've worked around this issue by loading and overwriting the SOFA files generate with the matlab API using a python implementation of the SOFA conventions, namely this one: https://github.com/spatialaudio/python-sofa.
Here is a sample code for doing that:

HRTF = sofa.Database.open(file_path, 'r+')
HRTF.save()
HRTF.close()

Hope it helps.

[lakulish]

We tested the SOFA file you provided, and the issue was the same as in #123, i.e., in the HDF5 superblock version. The workaround you're using is also similar to the one I mentioned in that issue. Thanks!

[miccio-dk]

Hey @lakulish , unfortunately I celebrated prematurely, the aforementioned command doesn't seem to work all the times.
I've tried a similar procedure using this SOFA library and I still can't get SteamAudio to read the file.
Internally, SOFASonix uses NetCDF4 which, in turn, relies on the libnetcdf and hdf5 C libraries. I've tried both the latest version (1.5.4) of NetCDF4 hosted on conda-force, which is packed with libnetcdf 4.7.4:

netCDF4.getlibversion()
# '4.7.4 of Oct 21 2020 19:59:39 $'

as well as as compiled my own version using libnetcdf 4.4.0 and hdf5 1.8.17

netCDF4.getlibversion()
# '4.4.0 of Feb 18 2017 10:01:44 $'

Unfortunately, SOFA files exported with neither versions worked.
However, when inspecting the resulting SOFA files with h5debug, I can see that at least in the second case, the superblock version is indeed the right one:

$ h5debug subj_K.sofa
Reading signature at address 0 (rel)
File Super Block...
File name (as opened):                             subj_K.sofa
File name (after resolving symlinks):              subj_K.sofa
File access flags                                  0x00000000
File open reference count:                         1
Address of super block:                            0 (abs)
Size of userblock:                                 0 bytes
Superblock version number:                         2
Free list version number:                          0
Root group symbol table entry version number:      0
Shared header version number:                      0
Size of file offsets (haddr_t type):               8 bytes
Size of file lengths (hsize_t type):               8 bytes
Symbol table leaf node 1/2 rank:                   4
Symbol table internal node 1/2 rank:               16
File status flags:                                 0x00
Superblock extension address:                      UNDEF (rel)
Shared object header message table address:        UNDEF (rel)
Shared object header message version number:       0
Number of shared object header message indexes:    0
Address of driver information block:               0 (rel)
Root group symbol table entry:
   Name offset into private heap:                  0
   Object header address:                          48
   Cache info type:                                Nothing Cached

Furthermore, I can see that the SOFA files generated by MATLAB 2019b using the matlab/octave API feature the following metadata:

_NCProperties: version=1|netcdflibversion=4.6.1|hdf5libversion=1.8.12

whereas the one exported using SOFASonix + netCDF4 (conda-force build) reads:

_NCProperties: version=2,netcdf=4.7.4,hdf5=1.10.6

Unfortunately, this field is not available in any of the public HRTF set I consulted, nor is updated when using libnetcdf 4.4.0.

Would you perhaps be able to mention exactly which tool (as well as its version and host OS) are you using to successfully create or export SOFA files that can be read by SteamAudio? It would really help us out!

I'm attaching the unabridged HRTF for convenience. This one is the one created with libnetcdf 4.4.0. It claims to have superblock version 2 but still won't work on SteamAudio. Feel free to take a look: subj_K.sofa.zip

Thanks again!

[miccio-dk]

A little follow-up: we were able to export SOFA files successfully using MATLAB 2016b, which features the right combination of hdf5 and netcdf libraries :)

[lakulish]

Hi @miccio-dk,

Good to know you were able to successfully export your SOFA file from MATLAB and have Steam Audio read it. For our next release, we plan to update to the latest version of the SOFA loading library we're using, hopefully that will make this sort of issue much less common.

Closing this issue.