Skip to content

Commit

Permalink
Remove dezippering.
Browse files Browse the repository at this point in the history
This fixes #76.
  • Loading branch information
padenot committed Sep 23, 2015
1 parent a77a57c commit a133600
Showing 1 changed file with 15 additions and 9 deletions.
24 changes: 15 additions & 9 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -1960,12 +1960,6 @@ <h2 id="GainNode">The GainNode Interface</h2>
the <a href="#widl-GainNode-gain"><code>gain</code></a> <a><code>AudioParam</code></a>.
</p>

<p>
The implementation must make gain changes to the audio stream smoothly,
without introducing noticeable clicks or glitches. This process is called
"de-zippering".
</p>

<dl title="interface GainNode : AudioNode" class="idl">
<dt>readonly attribute AudioParam gain</dt>
<dd>
Expand Down Expand Up @@ -2001,9 +1995,7 @@ <h2 id="DelayNode">The DelayNode Interface</h2>
time <em>t</em>, input signal <em>input(t)</em>, delay time
<em>delayTime(t)</em> and output signal <em>output(t)</em>, the output will be
<em> output(t) = input(t - delayTime(t))</em>. The default
<code>delayTime</code> is 0 seconds (no delay). When the delay time is
changed, the implementation must make the transition smoothly, without
introducing noticeable clicks or glitches to the audio stream.
<code>delayTime</code> is 0 seconds (no delay).
</p>

<dl title="interface DelayNode : AudioNode" class="idl">
Expand Down Expand Up @@ -5975,6 +5967,20 @@ <h3>Audio buffer copying</h3>
</p>
</section>

<section class=informative>
<h3>AudioParam transitions</h3>
<p>
While no automatic smoothing is done when directly setting the
<a><code>value</code></a> attribute of an <a><code>AudioParam</code></a>, for
certain parameters, smooth transition are preferable to directly setting
the value.
</p>
<p>
Using the <a><code>setTargetAtTime</code></a> method with a low
<code>timeConstant</code> allows authors to a perform smooth transition.
</p>

This comment has been minimized.

Copy link
@rtoy

rtoy Sep 25, 2015

Member

Should we have included a (non-normative) hint on a typical time constant value? I think Chrome's implementation used a value of about 10-20 ms or so.

</section>

<section>
<h3>Audio Glitching</h3>

Expand Down

0 comments on commit a133600

Please sign in to comment.