- From: Chris Wilson <cwilso@google.com>
- Date: Thu, 15 Aug 2013 08:00:00 -0700
- To: Chris Lowis <chris.lowis@bbc.co.uk>
- Cc: Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, Audio WG <public-audio@w3.org>
- Message-ID: <CAJK2wqWiEs_ksEJa+Hf=M2Mr0yYS59QQMo5p99t7D7nV5twX+Q@mail.gmail.com>
You should probably define it at the AudioParam level, but explicitly define for each AudioParam whether it is on or off. We have dezippering turned on for all AudioParams, and we have had multiple bug reports of portamento-like effects due to oscillator.frequency.value settings not taking immediate effect - believe we have a bug on this somewhere, and I've mentioned to Chris we need to be much less aggressive about de-zippering. De-zippering makes sense for gain, but I'm not convinced it does for all params; and, of course, developers can always do it themselves (by calling setTargetAtTime(now)). On Thu, Aug 15, 2013 at 5:10 AM, Chris Lowis <chris.lowis@bbc.co.uk> wrote: > > Olivier Thereaux writes: > > * ACTION-66: Look into what dezippering in webkit was based on (on Chris > Lowis) > > https://www.w3.org/2011/audio/track/actions/66 > > I've started on this - I think I have a good understanding on what the > algorithm is based on, and it looks straight-forward enough to spec. I'm > trying to work out where the specification belongs, because it appears > that "dezippering" should be applied at the AudioParam level rather than > just on the GainNode. > > I'll write up more in the bugzilla ticket shortly. > > Cheers, > > Chris > > > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and > may contain personal views which are not the views of the BBC unless > specifically stated. > If you have received it in > error, please delete it from your system. > Do not use, copy or disclose the > information in any way nor act in reliance on it and notify the sender > immediately. > Please note that the BBC monitors e-mails > sent or received. > Further communication will signify your consent to > this. > ----------------------------- >
Received on Thursday, 15 August 2013 15:00:30 UTC