[openal] Support SOFA in OpenAL?

Christian Hoene christian.hoene at symonics.com
Sun Jan 22 07:53:27 EST 2017

Hi Chris,

the new libmysofa version 0.4 has been released. It includes the normalization, efficient filter lookup, and filter interpolation. 

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 ;-)


More information about the openal mailing list