[openal] HRTF sound coloring

[Chris Robinson]

On 02/04/2017 02:35 PM, Ian Reed wrote:
> Our sound designer feels this makes the sound feel compressed, or that
> it is missing some frequencies.
> He notices it most with voice acted dialogue, as in the example we shared.

The HRTF could certainly be better. Not only is it pretty dependent on 
the individual (different heads will affect the sound differently), it's 
also derived from a 20-year-old data set. There's also some 
quality-vs-performance trade-offs being made. I do think it's quite 
decent for general use, especially considering it needs to handle many 
sources in real-time, but it's not unexpected for more trained ears to 
tell something's off.

> It sounds like the AL_SOFT_direct_channels extension and converting
> these mono sounds to stereo might be the path we need to follow.
> Is there a simple algorithm I can use to convert mono to stereo as the
> buffers are loaded?
> Maybe just this?
> L = M/2
> R = M/2

Yeah, that will work fine. You can also try
L = M / sqrt(2)
R = M / sqrt(2)
which may better preserve the apparent loudness of the original.


This does make me wonder if I made a mistake with 
AL_SOFT_direct_channels. Currently it's defined to map input buffer 
channels directly to an output channel based on label (e.g. front-left 
input goes directly to front-left output, instead of being panned to the 
front-left position regardless if there's a speaker there or not and 
regardless of how panning works). Part of me thinks I should have 
instead "folded" unmatched inputs to what's available for output (e.g. 
mapping rear channels to front if there are no rear/side outputs) and 
should handle mono with it on by mapping it to all positional speakers 
with appropriate scaling.

I could change it, but I worry that existing apps already rely on 
unmatched channels being dropped, or rely on mono sounds being 
unaffected by the property. I'd need a new extension to maintain 
compatibility.