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

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.

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.

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
>