[openal] Support SOFA in OpenAL?

[Christian Hoene]

Hi Chris,

the new libmysofa version 0.4 has been released. It includes the normalization, efficient filter lookup, and filter interpolation. 
https://github.com/choene/libmysofa

With the new version of libmysofa, it would be even easier to support SOFA in OpenAL-Soft, because you do not need the netcdf libraries, you do not have to implement new HRTF lookup and interpolation algorithm, and a you not new storage format for OpenAL.

The more I think, the less sense it makes to continue the approach I have started in https://github.com/choene/openal-soft (with the vanilla NETCDF and SOFA libraries and extending OpenAL to support SOFA), but to use libmysofa everytime OpenAL-Soft needs a new set of FIR filters...

With best regards,

 Christian Hoene



-----Ursprüngliche Nachricht-----
Von: Christian Hoene [mailto:christian.hoene at symonics.com] 
Gesendet: Sonntag, 18. Dezember 2016 10:56
An: Chris Robinson <chris.kcat at gmail.com>
Betreff: Re: Support SOFA in OpenAL?

> I'm not sure. The idea of makehrtf is to ensure the HRTF data is in a 
> convenient layout that's both small and quick to load, and ensures the 
> data is laid out in a way that OpenAL Soft can use it. As far as I can 
> tell, SOFA files have quite a few parameters, and data can be 
> expressed in a few different ways, so would require some processing 
> and a bunch of verification just to load one for the device. Having 
> makehrtf convert SOFA files to OpenAL Soft's format gives an 
> opportunity to alert the user that a dataset won't work, to provide 
> options for how to use it, or to do the more heavy processing once so it loads quicker at run-time.

Yes, the makehrtf format is more compact and faster to read than SOFA. 

My main intention is to enable OpenAL do have the HRTF even at run-time.

> 
> > 2) Does somebody still need the SOFA reader based on NetCDF and HDF5 
> > in makehrtf? Shall this be continued?
> 
> Again, I'm not sure. Considering SOFA files use the NetCDF format,
> libnetcdf/libhdf5 would be the appropriate way to read them. But 
> having a small, self-contained C library to load SOFA files would be 
> ideal. It depends on how thoroughly a C library handles all the format 
> features and quirks possible of SOFA files (not just existing ones, 
> but most or all of what the standard allows for), and how cleanly it 
> deals with the unexpected.

We are working closely together with the HDF group to ensure. Soon, we will have a first common blog entry about libmysofa.

You can compare libhdf5 and libmysofa with Adobe PDFs. libhdf5 is Acrobat and libmysofa is Acroread.

> 
> > 3) May I kick out the proprietary file HRTF format of OpenAL? Who 
> > will need this anyhow?
> 
> As much as I'd like to drop OpenAL Soft's mhr format and just load 
> SOFA files directly, I think the preprocessing is still necessary to 
> ensure correctness, load quickly, and be alterable for the users' 
> needs (resampling a 44.1khz IR to 48khz or vice-versa, changing the 
> minimum-phase cutoff length, etc).
> 
> I think a middle-ground would be to better integrate makehrtf with 
> alsoft-config. So for example, in the GUI you would switch to the HRTF 
> tab and click an Import Dataset... button, which brings up a dialog to 
> select an input file (.def or .sofa) and set various options for it 
> (sample rate, diffuse-field equalization, etc), then proceeding would 
> invoke makehrtf and save the output in the appropriate user directory 
> for OpenAL Soft to automatically see it.

This makes sense. Then you can change HRTF dynamically...

Expect to get many small patched in the next weeks ;-)

Best
 Christian