[admin] Assigning items currently being worked on by editor.

Changeset from the editor: 
https://dvcs.w3.org/hg/audio/rev/3837e5414cad

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
»

More detail added in:
https://dvcs.w3.org/hg/audio/rev/3837e5414cad

(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.

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>

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.

OK.

Fixed:
https://dvcs.w3.org/hg/audio/rev/b70ebeca5d18

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.