[openal] HRTF redesign
dejay at r3z.me
Thu Dec 4 23:14:35 EST 2014
On 03.12.2014 10:14, developer at oldunreal.com wrote:
> Sorry for answering this late, it's just that I yesterday became
> really aware about HRTF which went into OpenAL-Soft the first time. I
> personally would always put positional accuracy over performance cost.
> It's the most important thing when it comes to HRTF, the reason why
> people want to use it.
> Also, with nowadays still increasing CPU power the performance seems
> to become more and more the minor factor either way.
I agree. Quality > performance in this case. I have yet to play around
with head tracking but
I think HRTF will play a big role once the oculus rift / VR headsets
hits the market.
> On 19.11.2014 11:01, Chris Robinson wrote:
>> Hey guys.
>> I've been giving some serious thought to redesigning how HRTF mixing
>> works. Currently, it works in a fairly straight-forward, if somewhat
>> costly, way... when a source updates, its direction is used to lookup
>> the filter coefficients (really, the four nearest sets for bilinear
>> interpolation) which are then used to apply a FIR filter for the
>> source input to two output channels. There's also per-sample stepping
>> to fade between coefficients as the source pans around and the
>> attenuation changes.
>> A possible alternate way, I think, is by mixing normally to a virtual
>> 14-channel setup (8-channel cube + 6-channel "diamond"), then apply
>> HRTF to those channels for output. This has the obvious drawback that
>> it loses some positional accuracy, but it does have a few benefits.
>> First, it simplifies HRTF setup since it only needs to calculate
>> coefficients once on device reset, and avoids any need for per-sample
>> stepping. Secondly, HRTF processing then becomes a fixed cost. The
>> HRTF filter applies to the 14 channels, irrespective of however many
>> sources are playing. It also affects the output of effects.
>> As well, it improves B-Format handling since it would mix into 14
>> distinct channels around the listener, which then get filtered for a
>> more encompassing result instead of simple stereo.
>> But... I'm not sure how bad the positional accuracy loss will be,
>> especially given the ambisonics-based panning which would spread the
>> signal out across multiple (virtual) channels. Though maybe the way
>> the channel volumes are balanced will still provide good positioning
>> cues. So I'm curious if anyone has any thoughts on this.
>> openal mailing list
>> openal at openal.org
> openal mailing list
> openal at openal.org
More information about the openal