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: Raymond Toy <rtoy@google.com>
Date: Fri, 25 May 2012 11:22:30 -0700
Message-ID: <CAE3TgXF79k-xQLP0CRK2dB6HwDaNfgHJBefhNfprb2vo3CSjcQ@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Audio Working Group <public-audio@w3.org>, olivier Thereaux <olivier.thereaux@bbc.co.uk>
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.

Ray
Received on Friday, 25 May 2012 18:23:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 May 2012 18:23:05 GMT