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

Re: Audio-ISSUE-19 (SamplingFormat): Define sampling format [Web Audio API]

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 25 May 2012 15:49:23 +0200
To: "Audio Working Group" <public-audio@w3.org>, "olivier Thereaux" <olivier.thereaux@bbc.co.uk>
Message-ID: <op.weu90l04sr6mfa@kirk>
On Fri, 25 May 2012 12:36:51 +0200, olivier Thereaux  
<olivier.thereaux@bbc.co.uk> wrote:

> On 15 May 2012, at 13:44, Audio Working Group Issue Tracker wrote:
>> Audio-ISSUE-19 (SamplingFormat): Define sampling format [Web Audio API]
>> http://www.w3.org/2011/audio/track/issues/19
>> Raised by: Marcus Geelnard
>> On product: Web Audio API
>> In the internal sample format the interpretation of Float32 NaN, +-Inf  
>> etc is not defined. More generally, it seems to not be defined what the  
>> sampling format of everything is (AudioBuffer, WaveShaperNode, etc).
> This issue is now pending review, per  
> https://dvcs.w3.org/hg/audio/rev/b4680b4ee21d

The definition of float should be left to WebIDL:  

What we wanted to know is how to interpret NaN and Infinity when passing  
the data on to the actual hardware. The best way to spec this might be as  
a clamping step in AudioDestinationNode, to say that NaN is interpreted as  
0 and all other values are clamped to the [-1, 1] range. In other words,  
Infinity becomes 1 and -Infinity -1, such that it is well defined how a  
JavaScript generating a square wave oscillating between infinities will  

We think that there will be inconsistencies between implementations in how  
NaN values in the input of the various nodes affect the output, since it  
depends a lot on the implementation technique. We're not going to suggest  
defining that exactly at this point, but we may have reason to re-visit it  
when implementing.

Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 25 May 2012 13:50:58 UTC

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