17399 2012-06-05 12:19:24 +0000 (AudioParamSampling): AudioParam sampling is undefined 2014-10-28 17:16:41 +0000 1 1 1 Unclassified AudioWG Web Audio API unspecified PC All CLOSED FIXED P2 normal TBD 1 mike crogers olivier.thereaux ot philipj public-audio roc dave.null oldest_to_newest 68711 0 mike 2012-06-05 12:19:24 +0000 Audio-ISSUE-42 (AudioParamSampling): AudioParam sampling is undefined [Web Audio API] http://www.w3.org/2011/audio/track/issues/42 Raised by: Philip Jägenstedt On product: Web Audio API It is not defined how the AudioParam values (ramps or AudioNode input) are sampled. These approaches would yield hugely different results: * Sample-and-hold at the beginning of each processing buffer (if they exist in the implementation). * Correct downsampling with low pass filtering to below the Nyquist frequency for each processing buffer. This could turn a 20KHz signal into silence. * Continuously per audio sample at the mixing level. Slow? 68785 1 olivier.thereaux 2012-06-07 08:17:23 +0000 [admin] Assigning items currently being worked on by editor. 68810 2 olivier.thereaux 2012-06-07 14:53:02 +0000 Changeset from the editor: https://dvcs.w3.org/hg/audio/rev/3837e5414cad 68811 3 olivier.thereaux 2012-06-07 14:53:51 +0000 Feedback from Philip in http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0433.html «This is certainly an improvement! More feedback: The sampling of k-rate parameters is not defined, the sensible options would seem to be either the average value over one working buffer (128 samples) or picking the first, middle or last sample for that work buffer. In other words, if a signal oscillating between 0 and 1 at 20 KHz oscillator is used to control delayTime, will it be effectively a constant 0.5 second delay or a "random" delay for each work buffer depending on the phase of the signal? Editorial issues: "Please note that the <code>frequency</code>, <code>Q</code>, and <code>gain</code> parameters are <em>k-rate</em>" can be replaced with "All parameters are <em>k-rate</em>". Lowercase and uppercase MUSTs are now both used, presumably not intentionally. Typo: coursely -> coarsely » 68879 4 crogers 2012-06-08 20:03:06 +0000 More detail added in: https://dvcs.w3.org/hg/audio/rev/3837e5414cad 68912 5 olivier.thereaux 2012-06-11 11:44:06 +0000 (In reply to comment #2) > Changeset from the editor: > https://dvcs.w3.org/hg/audio/rev/3837e5414cad For the record: the "older" changeset was https://dvcs.w3.org/hg/audio/rev/0f614b03b8cb https://dvcs.w3.org/hg/audio/rev/3837e5414cad is the new changeset, addressing the concerns and suggestions from comment #3. 68951 6 philipj 2012-06-12 08:34:16 +0000 What spec says is now mostly correct, but the wrong part is normative. What implementation *actually* have to do is sample at the beginning of a each 128-sample block, but this is not normative. Conversely, the 3ms requirement *is* normative, even though 3ms at 8KHz is 24 samples and not what will actually be implemented. Suggestion: Remove all mention of 3ms and state: <p> Implementations must use block processing, with each <code>AudioNode</code> processing 128 sample-frames in each block. </p> and <p> For each 128 sample-frame block, the value of a <em>k-rate</em> parameter must be sampled at the time of the very first sample-frame, and that value must be used for the entire block. </p> 68953 7 philipj 2012-06-12 08:52:54 +0000 To clarify, the section mentioning 3ms would be rewritten to end in something like "a <em>k-rate</em> parameter whose value changes must be taken at the beginning of each 128 sample-frame block." 69098 8 roc 2012-06-15 15:38:45 +0000 Was it decided to specify sampling in terms of the number of samples instead of a time duration? I prefer the use of a time duration (gives the implementation more flexibility to be sample-rate-independent), and I thought the discussion on the mailing list about the minimum delay for DelayNodes was heading that way. 69100 9 philipj 2012-06-15 15:52:03 +0000 If defined in seconds, (In reply to comment #8) > Was it decided to specify sampling in terms of the number of samples instead of > a time duration? Nope, it's still an open issue here and for enforcing minimum delays in loops. > I prefer the use of a time duration (gives the implementation more flexibility > to be sample-rate-independent), and I thought the discussion on the mailing > list about the minimum delay for DelayNodes was heading that way. What do you mean by sample-rate-independent in this context? If two implementations running at the same sampling rate don't sample AudioParam at exactly the same interval (in samples) then they won't sound the same. My favorite example is when the AudioParam is a high-frequency sine wave, where the result of sampling every n samples and every n+1 samples may be audibly different. I think that in order to define the sampling in terms of seconds, the AudioParam must also be correctly down-sampled to avoid this. 69101 10 roc 2012-06-15 16:39:25 +0000 OK. 75465 11 crogers 2012-10-06 01:14:50 +0000 Fixed: https://dvcs.w3.org/hg/audio/rev/b70ebeca5d18 76087 12 philipj 2012-10-12 11:48:10 +0000 Looks good now. 114014 13 olivier.thereaux 2014-10-28 17:16:41 +0000 Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.