This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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).
[admin] Assigning items currently being worked on by editor.
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. »
(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.
Web Audio API issues have been migrated to Github. See https://github.com/WebAudio/web-audio-api/issues
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.