Bug 17399 - (AudioParamSampling): AudioParam sampling is undefined
Summary: (AudioParamSampling): AudioParam sampling is undefined
Status: CLOSED FIXED
Alias: None
Product: AudioWG - OBSOLETE - Moved to Github
Classification: Unclassified
Component: Web Audio API - OBSOLETE - See Github (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: TBD
Assignee: Chris Rogers
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-05 12:19 UTC by Michael[tm] Smith
Modified: 2014-10-28 17:16 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael[tm] Smith 2012-06-05 12:19:24 UTC
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?
Comment 1 Olivier Thereaux 2012-06-07 08:17:23 UTC
[admin] Assigning items currently being worked on by editor.
Comment 2 Olivier Thereaux 2012-06-07 14:53:02 UTC
Changeset from the editor: 
https://dvcs.w3.org/hg/audio/rev/3837e5414cad
Comment 3 Olivier Thereaux 2012-06-07 14:53:51 UTC
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
»
Comment 4 Chris Rogers 2012-06-08 20:03:06 UTC
More detail added in:
https://dvcs.w3.org/hg/audio/rev/3837e5414cad
Comment 5 Olivier Thereaux 2012-06-11 11:44:06 UTC
(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.
Comment 6 Philip Jägenstedt 2012-06-12 08:34:16 UTC
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>
Comment 7 Philip Jägenstedt 2012-06-12 08:52:54 UTC
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."
Comment 8 Robert O'Callahan (Mozilla) 2012-06-15 15:38:45 UTC
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.
Comment 9 Philip Jägenstedt 2012-06-15 15:52:03 UTC
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.
Comment 10 Robert O'Callahan (Mozilla) 2012-06-15 16:39:25 UTC
OK.
Comment 11 Chris Rogers 2012-10-06 01:14:50 UTC
Fixed:
https://dvcs.w3.org/hg/audio/rev/b70ebeca5d18
Comment 12 Philip Jägenstedt 2012-10-12 11:48:10 UTC
Looks good now.
Comment 13 Olivier Thereaux 2014-10-28 17:16:41 UTC
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.