[openal] HRTF sound coloring
chris.kcat at gmail.com
Sun Feb 5 04:22:01 EST 2017
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
More information about the openal