Re: De-zippering

On Fri, Nov 8, 2013 at 1:12 AM, Marcus Geelnard <mage@opera.com> wrote:

>  If we didn't have dezippering (in my mind the better choice), I see
> three outcomes regarding the less educated Web developers (who are very
> likely to have just copy/paste:d some code off the Web to start with):
>
>  1) They will not hear the glitch artifacts, and will not care, because
> it's non-critical for their app.
>  2) They will hear the glitch artifacts, be annoyed, google for it and
> will find an answer on stackoverflow, MDN or html5rocks, for example. If it
> takes more than 3 minutes of googling, they might even turn to the spec and
> check out how to control an AudioParam - so that might be a good place to
> add an advisory note.
>

2a) They will hear the zippering, not understand what's causing it or how
to describe it, and not be able to figure out how to google "web audio
sounds gronky" in a meaningful way.


> I still think that the primary purpose of a Web standard such as Web Audio
> is to act as a technology enabler. If there's a choice between ease of use
> and more power to the developer, I tend to pick the latter. Rationale: The
> former can be added on top of the API, while the latter can not.
>

If that were the choice here, I would agree with you.  We're not faced with
a tradeoff in power; either way (auto-dezippering or not), there's a clear
way to do the other behavior for an informed developer.


> If we're going to have parameter value smoothing, we should definitely
> have an on/off option, per AudioParam (you might even argue that you should
> be able to control the individual smoothing parameters). It's impossible to
> decide which param should have it or not based on common sense. I'd also
> argue that we should have all off or all on as default, for consistency.
>

 IIRC, the smoothing is simply a single parameter - it's essentially
calling setTargetAtTime.  I wouldn't bother offering control; you can
always call setTargetAtTime with a different value.