Re: Audio-ISSUE-42 (AudioParamSampling): AudioParam sampling is undefined [Web Audio API]

On Fri, 25 May 2012 11:25:31 +0200, olivier Thereaux  
<olivier@thereaux.net> wrote:

> On 15 May 2012, at 15:43, Audio Working Group Issue Tracker wrote:
>
>> 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?
>
> This issue is now Pending Review, per  
> https://dvcs.w3.org/hg/audio/rev/0f614b03b8cb

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

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Friday, 25 May 2012 13:36:19 UTC