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

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.

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.

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.