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: Mon, 28 May 2012 10:13:28 +0200
To: "Raymond Toy" <rtoy@google.com>
Cc: "Audio Working Group" <public-audio@w3.org>, "olivier Thereaux" <olivier.thereaux@bbc.co.uk>
Message-ID: <op.we0egqoksr6mfa@kirk>
On Fri, 25 May 2012 20:22:30 +0200, Raymond Toy <rtoy@google.com> wrote:

> On Fri, May 25, 2012 at 6:49 AM, Philip Jägenstedt  
> <philipj@opera.com>wrote:
>> 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<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 <https://dvcs.w3.org/hg/audio/rev/b4680b4ee21d>
>> The definition of float should be left to WebIDL:
>> http://www.w3.org/TR/WebIDL/#**idl-float<http://www.w3.org/TR/WebIDL/#idl-float>
>> 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
>> sound.
>> 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.
> It seems that once a NaN or infinity has been generated, something
> seriously wrong is going on and should be fixed there.  Having to check  
> for
> NaN or infinity on the input of every node seems like a lot of overhead  
> for
> a situation that should not occur at all.  This excludes your example of  
> a
> JavaScript node generating infinities on purpose.  I don't understand why
> you would want to do that in practice.

Of course script should not intentionally generate NaN or infinities, but  
like with all Web-facing APIs we can be 100% certain that people will  
accidentally do it. WebKit must already do *something* in this situation,  
so we can just spec that if it makes sense. With offline audio contexts,  
the result will be script-visible and a complete test suite must cover  
this case.

Philip Jägenstedt
Core Developer
Opera Software
Received on Monday, 28 May 2012 08:13:56 UTC

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