Allow binding external HRTF implementations

[ddiakopoulos]

The HRTF implementation in LabSound is well functioning, but large code surface area. Support for ambisonics and other HRTF models would be helpful but require further complexity. Proposal: wrap the audio spatialization features of the Steam Audio SDK into a core node for LabSound, replacing all existing HRTF/HRTFPanner code.

https://github.com/ValveSoftware/steam-audio/releases

The Steam Audio SDK is "openly" licensed, but not OSS. Middleware in the strict sense of the word. It breaks my philosophy not to include binary dependencies in LabSound, but the features might be worth it.

What do you say, @meshula ?

[meshula]

It wouldn't hurt to factor the HRTF node into an add-on module. Waiting for the HRTF database to load when you're not using it is sub-optimal.

From 10,000 feet, there should probably be a generic interface on spatialization nodes so that various implementations can be dropped in replacably to existing graphs.

[ddiakopoulos]

Hehe, I actually changed it a while ago so a PannerNode loads the database on-demand if one is created by specifying the hrtf search path:

LabSound/src/core/PannerNode.cpp

Line 43 in 0438183

m_hrtfDatabaseLoader = HRTFDatabaseLoader::MakeHRTFLoaderSingleton(sampleRate, stripSlash(searchPath));

[meshula]

Nice :)

So same as with factoring the HRTF into an add-on, no issue with having Steam Audio SDK as an optional add-on.

I haven't been able to think of a meaningful base class in the last ten minutes, but I still think it's a reasonable idea ;)

[meshula]

I think it makes sense to add an additional CustomPanningNode (name?) that allows an external algo, such as the one in the Steam SDK, to be bound by function pointers, subclassing, or lambdas (pick one?). I'd rather leave the existing HRTF in place as it is open, and functional.

[meshula]

See also

• https://github.com/GoogleChrome/omnitone
• https://github.com/resonance-audio/resonance-audio-web-sdk

[meshula]

@ddiakopoulos The original comment notes that the HRTFPanner has a large code surface. I just did a pass (pushed to main) to consolidate all the scattered objects into a small number of files in order to reduce exposed API. At this point it would be easy to add more spatialization routines, but I would suggest that we keep the standard webaudio one, and simply introduce new models by extending the enumeration with a new PanningModel named Custom, and adding a "set function pointers" function that takes a processing function pointer to invoke, and other utility functions for initialization and so on, basically anywhere we switch on PannerModel we'd have a corresponding function pointer.