Re: [Bug 21550] New: PannerNode - include informative note on HRTF, point to reference/open examples

On Thu, Apr 4, 2013 at 3:28 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Apr 4, 2013 at 10:22 PM, Chris Lowis <chris.lowis@bbc.co.uk>wrote:
>
>> My thinking here was that there's a couple of nodes in the spec that are
>> perhaps hard to specify mathematically (the compressor node, for
>> example) and that even if we could, my preference leans towards
>> attempting to specify the intended effect while leaving implementations
>> to compete in terms of performance or sound quality. Is that even a
>> desirable goal?
>>
>
> I think allowing browsers to compete on quality is fine if authors always
> agree on which outputs are higher quality, i.e. that for given outputs A
> and B either everyone agrees that A is at least as good as B, or everyone
> agrees that B is at least as good as A, and everyone understands that both
> A and B are acceptable outputs according to the spec, and the difference in
> output is not so large that authors don't trust it.
>
> I worry that this won't be the case for competing HRTF models. I don't
> know enough about HRTF but isn't it the case that different developers
> favour different models?
>

This is a valid concern.  For these types of effects (HRTF spatialization,
dynamics compression) people are not always in agreement about the best
sound quality.  At the extremes, for very bad and very good sounding
algorithms most people may agree.


>
> In the case of the HRTF setting for the Panner node my preference would
>> be:
>>
>> - allow developers to load their own HRTF into the Node[1]
>> - word the spec such that an implementation MAY provide a default HRTF
>>   set, and if they do,
>>
>
I believe the implementation must implement a default HRTF set.  Otherwise,
the PannerNode will not "just work" out of the box.


> - it SHOULD be derived from the IRCAM set that Webkit have used up to
>>   this point.
>>
>
> I don't think we should allow implementations to vary based on whether an
> HRTF set is provided. Either all should or none should, and since Webkit
> does, that means all should.
>
> Letting authors supply their own HRTF sounds great but it could wait for a
> later iteration of the spec I think.
>

Seems reasonable for the current spec.  But, I hope that people like the
BBC can start some early work on what a reasonable API might look like,
along with some prototype implementation.


>
> Rob
> --
> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
> qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
> qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq
> qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq
> qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q
> qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
>