[openal] HRTF queries
flibitijibibo at flibitijibibo.com
Fri Jun 20 19:44:46 EDT 2014
You might be able to design it similarly to the OpenGL shader API, but
without the need for programs/linking on top of shaders. For instance,
alcCreateHRTFs(ALint, ALint*), alcBindHRTF(ALint),
alcAttachHRTFSource(ALchar*), alcParseHRTF(), etc. This would be nice
for multiple HRTF profiles, and would prevent the need to require a
specific way of loading them in the implementation. AL Soft can just do
the parsing, and where that source comes from is up to the application.
How you want to query specific things, may depend on what the properties
are... but it sounds like the actual profile management is 99% of the
If it's possible to keep non-stereo HRTF in the spec, it might be
important for when it comes up later. I don't think it'd be a problem to
only have stereo support in the implementation, though.
On 6/20/14, 7:32 PM, Chris Robinson wrote:
> Hey guys.
> I'm currently trying to finish up the ALC_SOFT_HRTF extension, and
> there's a few design considerations I need to tackle. Currently the
> extension is just a simple toggle on the device, and HRTF gets enabled
> if requested and a compatible format can be set. However, it would be
> reasonable to have an API that can enumerate multiple HRTF sets, even
> those that use the same format, so that the app can select specific ones.
> Ideally, this API would be able to provide names for the HRTF data
> sets, whether it be a filename or some kind of identifier (like device
> enumeration). And in consideration of loopback devices that work with
> user-specified formats, the app needs to be able to query the format
> it uses.
> Are there any ideas for how an API would be? The current OpenAL API
> doesn't seem to be designed with the idea of querying string lists or
> setting one as a device property, so I'd like to get thoughts and
> ideas before throwing stuff together.
> And a final thing. Right now, OpenAL Soft has the idea that HRTF does
> not strictly have to be stereo. This strikes me as both reasonable
> (could there be HRTFs that work with more than 2 channels?) and a bit
> silly (OpenAL Soft will only do HRTF with stereo). So I'm probably
> going to get rid of the idea of non-stereo HRTFs internally. However,
> should the public HRTF API consider the possibility of non-stereo HRTF?
> openal mailing list
> openal at openal.org
More information about the openal