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

On Mon, Apr 22, 2013 at 8:34 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> I was about to bring up the question about the exact algorithms used by
> DynamicsCompressorNode, BiquadFilterNode and friends, but I think all of
> the arguments brought up in this thread applies similarly to those.
>

I think the biquad filters are in a different category since they're pretty
much an "industry standard" design based on the way 2nd order filters can
be usefully configured.


>
> Also, I agree that unless crogers is open to the idea of changing the
> algorithms/datasets used in such nodes, it probably makes sense to spec
> what WebKit/Blink do today.  FWIW, today I checked in code into Gecko to
> adopt Blink's Dynamics Range Compression code and I'm planning to do the
> same for BiquadFilterNode soon.
>

We can always add additional compression algorithms in the future by adding
something like an .algorithm attribute which would default to the current
one, but could be set to others - just a thought...



>
> Cheers,
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
> On Thu, Apr 18, 2013 at 7:51 AM, Marcus Geelnard <mage@opera.com> wrote:
>
>> **
>> Den 2013-04-18 12:52:03 skrev Chris Pike <Chris.Pike@bbc.co.uk>:
>>
>>
>> On 18 Apr 2013, at 09:43, "Marcus Geelnard" <mage@opera.com> wrote:
>>
>> Den 2013-04-17 23:21:47 skrev Robert O'Callahan <robert@ocallahan.org>:
>>
>> This is an area where the Web platform may differ from expectations
>> you've built up working on other platforms.
>>
>> My experience with other Web APIs is that many (but not all) authors and
>> users are more concerned about consistency across implementations and
>> across time than whether one implementation "looks better" than other. So
>> we'll make a change that we think improves aesthetics and some (but not
>> all) authors/users will raise hell because we "broke their site". Or we'll
>> implement something differently from other browsers and authors/users will
>> complain that we're "not doing it right". And of course 10% of
>> authors/users being vocally angry and the rest being quietly satisfied with
>> a small improvement is actually a loss for us. I prefer to avoid getting
>> into those situations if we can. And generally, if author requirements
>> force browsers to behave a certain way, that should be written into the
>> spec.
>>
>>
>> I totally agree here. I believe that in general serious developers are
>> mostly concerned with having a consistent platform to target (in this case,
>> "the Web"). Ask any game developer. I think there are roughly two ways for
>> Web developers of handling the issue of audio quality/behavior:
>>
>> 1) Throw something at the browsers, hope that they will do the best of
>> it, and don't care too much about "poor quality" in a few instances ("maybe
>> they will improve in the future"). This usually also implies that you don't
>> care too much about optimal quality.
>>
>> 2) Tune your set up and assets until you get the feel and quality that
>> you're looking for. You typically do this against a specific target. If
>> different browsers behave differently, you'll quickly start seeing
>> "Optimized for [browser X]" in games and Web apps, which is quite the
>> opposite to what we try to achieve here, IMO.
>>
>> I'd say that 2) is the case we should be more concerned about. In any
>> event, having a consistent behavior across browsers seems to me to be the
>> better option.
>>
>> /Marcus
>>
>>
>>
>> If it's an issue where everyone will agree whether one implementation is
>> better than another, this is less of a problem, but Chris' answers suggest
>> that is not the case for HRTF.
>>
>> (I mean Chris Rogers. Why is everyone called Chris? It's driving me mad!)
>>
>> Rob
>>
>>
>>
>>
>> --
>> Marcus Geelnard
>> Android Browser Developer
>> Opera Software ASA
>>
>>
>> I'm happy to follow your advice here since I am not from a web
>> background. However I do not feel comfortable with the idea of using the
>> HRTF used in the WebKit, without evidence that it is superior over other
>> choices.
>>
>> This is a complex topic, because a metric for quality of HRTF is not well
>> defined. Quality is known to vary significantly and is perceived
>> differently between individuals, since the HRTF is by its nature
>> individual. However studies have shown that some HRTFs show better
>> performance across a group of individuals than others, this is in terms of
>> localisation accuracy of virtual sound sources which is one part of the
>> quality.
>>
>> Since I'm not familiar with the process for web spec development it would
>> be interesting to know how important people believe it to be to validate
>> the choice of normative HRTF set in terms of sound quality. I can provide
>> some more background to the existing research if there is interest.
>>
>> If we do go with a normative reference HRTF then I think it's really
>> important to extend the spec (but probably in a later version) to allow
>> developers to provide their own alternative HRTF set.
>>
>>
>> Agreed. We should allow for other HRTF sets too (either custom or
>> pre-defined), but as you said that could be done in a later version. I
>> think that a well defined HRTF set should have higher priority than the
>> best possible [perceived] quality ATM.
>>
>> Unless there are some obvious flaws with the current WebKit/Blink data
>> set, I don't mind using it. Do you have any ideas about how to make an
>> assessment of the quality/suitability current WebKit HRTF set?
>>
>> There are other aspects to address in an informative note on HRTF panning
>> should address. For instance methods for interpolating transfer functions
>> for directions between the provide measurement points.
>>
>>
>> Yes, in the end we need to have a well defined output for any given input.
>>
>>
>> /Marcus
>>
>>
>> Best regards
>> Chris
>>
>>
>> http://www.bbc.co.uk
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
>> If you have received it in error, please delete it from your system.
>> Do not use, copy or disclose the information in any way nor act in
>> reliance on it and notify the sender immediately.
>> Please note that the BBC monitors e-mails sent or received.
>> Further communication will signify your consent to this.
>>
>>
>>
>>
>> --
>> Marcus Geelnard
>> Android Browser Developer
>> Opera Software ASA
>>
>
>