[Bug 17394] (SamplingFormat): Define sampling format

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17394

--- Comment #3 from Chris Rogers <crogers@google.com> ---
(In reply to comment #2)
> Changeset from the editor: https://dvcs.w3.org/hg/audio/rev/b4680b4ee21d
> 
> 
> Comment from Philip in
> http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0434.html
> «
> The definition of float should be left to WebIDL:  
> 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.
> »
> 
> 
> Comment from Ray in
> http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0436.html
> «
> 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.
> »
> 
> Comment from Philip in
> http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0443.html
> «
> 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.
> »

Currently WebKit doesn't do anything to specially handle these values.  If we
need to define/spec the behavior in the AudioDestinationNode, then I suggest
that NaN and Inf both be converted to 0

If there's a strong feeling that this needs to be specified, then we can do
that.  But, the reality is that these represent anomalous conditions and
regardless of approach taken, the rendered audio will sound messed up.  So, my
recommendation is to not fret about this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.