W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2013

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

From: Marcus Geelnard <mage@opera.com>
Date: Thu, 18 Apr 2013 10:43:28 +0200
To: "Chris Rogers" <crogers@google.com>, "Robert O'Callahan" <robert@ocallahan.org>
Cc: "Chris Pike" <chris.pike@bbc.co.uk>, "Chris Lowis" <chris.lowis@bbc.co.uk>, bugzilla@jessica.w3.org, "public-audio@w3.org" <public-audio@w3.org>
Message-ID: <op.wvqaiquxm77heq@mage-speeddemon>
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
Received on Thursday, 18 April 2013 08:48:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:18 UTC