Bugzilla – Bug 17399
(AudioParamSampling): AudioParam sampling is undefined
Last modified: 2014-10-28 17:16:41 UTC
Audio-ISSUE-42 (AudioParamSampling): AudioParam sampling is undefined [Web Audio API]
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?
[admin] Assigning items currently being worked on by editor.
Changeset from the editor:
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?
"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
Typo: coursely -> coarsely
More detail added in:
(In reply to comment #2)
> Changeset from the editor:
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.
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:
Implementations must use block processing, with each <code>AudioNode</code> processing 128 sample-frames in each block.
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.
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."
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.
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.
Looks good now.
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.