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

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