[openal] Enabling HRTF

developer at oldunreal.com developer at oldunreal.com
Wed Dec 3 03:42:16 EST 2014


Oh, didn't see this directly.
I think it should enforce both stereo and the sample rate. The "why" is 
easy to explain, in my experience people usually behave like this: they 
want an option, in this case something like  "use hrtf for their 
headphones" and if its set up and not working, it will only result in a 
bugreport. They don't like to read manuals or FAQs, they don't want to 
mess with different settings in order to make things work, they want to 
simply enable it and it has to be working then.
Otherwise, could make it depending if headphones are plugged in maybe, 
guess this would be the best solution, "enforce it if headphones", but I 
have to admit that I have absolutely no clue how reliably this can be 
detected, especially under consideration that I use OpenAL in Win/Lin 
X86 and ARM and OSX.

However, I wouldn't care checking these things myself and enforce it 
manually, but I think it would be the way I'd handle it, set the 
requirements to make it work, log it to make it obvious for anyone who 
cares and that's it.


On 02.12.2014 00:48, Chris Robinson wrote:
> Now, given one of those options, the follow-up question is how much 
> priority should this option have? For instance, if the device is 
> normally using 5.1 output, should enabling HRTF in one of these ways 
> try to force stereo output, or should it only use HRTF if output is 
> already stereo? Similarly for the sample rate, if the device would 
> normally use an incompatible rate, or the app specifically requested 
> an ALC_FREQUENCY that can't work with HRTF, should it still try to 
> make HRTF work by changing the sample rate? 



More information about the openal mailing list