- From: Marcus Geelnard <mage@opera.com>
- Date: Fri, 08 Nov 2013 10:12:21 +0100
- To: Chris Wilson <cwilso@google.com>, Joseph Berkovitz <joe@noteflight.com>
- CC: Chris Lowis <chris.lowis@gmail.com>, Audio WG <public-audio@w3.org>
- Message-ID: <527CAAF5.9020309@opera.com>
So here's my opinion... 2013-11-07 20:32, Chris Wilson skrev: > I'm going to express an opinion, too. :) Actually, two of them: > 1) "Anybody who has a little bit of experience in handling audio" is > not our (entire) market. Many web developers will never have heard of > this. > 2) Advisory notes will have no impact on this problem, because this > will be buried down thirty pages in to the spec. A new-to-Web-Audio > web developer won't read through that, they'll just wonder why their > audio sounds grungy. > 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. 3) They will be annoyed by the glitches (and other tricky parts of getting audio working the way you want), give up on trying to fix it, and turn to a higher level JS library that does things for you. 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. Of course, the trick is to find the balance, and that's where the debate is - and I just gave my opinon ;-) > sp: yes, you can schedule brutal changes with setValueAtTime - you can > today. The issue is what happens with .value. > > I'm starting to think the best way to fix this, actually, is to expose > a "dezippering" property on AudioParam, that defaults to on but 1) > makes it obvious what's happening, and 2) makes it easy to turn off. 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. /Marcus > > > On Thu, Nov 7, 2013 at 11:09 AM, Joseph Berkovitz <joe@noteflight.com > <mailto:joe@noteflight.com>> wrote: > > This feels like a good time to throw out opinions, so… > > I understand Chris R’s rationale, but like Marcus I think the > automatic dezippering was a mistake and will lead to the kind of > impossible decisions that Chris W is starting down, about where it > makes or doesn’t make sense. We’ll probably never agree on those > issues because there are equally valid arguments for any given > configuration of dezippering-or-not. > > So I would rather see the default behavior be no dezippering, and > go the advisory-note route of recommending the use of > exponentialRampAtTime(). Additionally, we might provide a > simplified version of the latter function that has the semantics > (but not the ugly name) of setDezipperedValue(). > > On Nov 7, 2013, at 1:23 PM, Chris Wilson <cwilso@google.com > <mailto:cwilso@google.com>> wrote: > >> Chris (Rogers)' reasoning behind implementing this way to begin >> with was that most users simply don't know about this at all. >> >> My personal feeling on this is that there are some scenarios that >> automatically applying dezippering on makes sense, and some it >> does not. For example, it would make sense to dezipper volume >> control; however, it does not make sense to dezipper frequency >> control. This leads me to think that it might be good to apply >> to gain.gain.value, but not to oscillator.frequency.value, for >> example. >> >> >> On Thu, Nov 7, 2013 at 3:51 AM, Marcus Geelnard <mage@opera.com >> <mailto:mage@opera.com>> wrote: >> >> 2013-11-07 12:23, Chris Lowis skrev: >> >> Hi! >> >> There's a task for me to look into how "dezippering" is >> performed in >> Webkit and to explain how and why we do it. >> >> I've put together a quick demo to show the effect of >> dezippering >> >> http://blog.chrislowis.co.uk/demos/dezippering/ >> >> And made some notes on how it is implemented on this ticket: >> >> https://github.com/WebAudio/web-audio-api/issues/76 >> >> I think it's open for debate whether we clarify >> dezippering (I think >> I'd prefer to use the term "parameter smoothing") in the >> spec, and all >> of the parameters to which it applies by default, or >> whether we move >> to remove mention of it altogether and perhaps add an >> advisory note >> about preventing glitches by using >> exponentialRampToValueAtTime() for >> example. >> >> For that reason, I haven't prepared a PR. Perhaps we can >> discuss it >> here first and I can prepare one later. >> >> >> In general I prefer not to have too much magic going on >> behind the scenes. >> >> The automatic smoothing (dezippering) in Web Audio reminds me >> of when progress bar smoothing logic was added to Windows >> Vista. In an attempt to create a more pleasant experience for >> the user, the new implementation left developers unable to >> control the progress bar the way they wanted to [1] (e.g. >> reaching 100% progress was almost impossible without fooling >> the API by utilizing known quirks in the underlying progress >> bar smoothing implementation). >> >> Let's not repeat that mistake. Unless there are strong use >> cases for automatic parameter smoothing that can not be >> handled using explicit interfaces, I'd prefer dropping it in >> favor of explicit interfaces. >> >> /Marcus >> >> >> >> [1] >> http://stackoverflow.com/questions/1061715/how-do-i-make-tprogressbar-stop-lagging >> >> >> >> Cheers, >> >> Chris >> >> >> >> -- >> Marcus Geelnard >> Technical Lead, Mobile Infrastructure >> Opera Software >> >> >> > > . . . . . ...Joe > > *Joe Berkovitz* > President > > *Noteflight LLC* > Boston, Mass. > phone: +1 978 314 6271 <tel:%2B1%20978%20314%206271> > www.noteflight.com <http://www.noteflight.com> > "Your music, everywhere" > > -- Marcus Geelnard Technical Lead, Mobile Infrastructure Opera Software
Received on Friday, 8 November 2013 09:12:56 UTC