[openal] HRTF queries

[Ethan Lee]

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 
work here?

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.

-Ethan

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
> http://openal.org/mailman/listinfo/openal