- From: Raymond Toy <rtoy@google.com>
- Date: Thu, 3 Mar 2016 09:10:54 -0800
- To: Chris Wilson <cwilso@google.com>
- Cc: Peter van der Noord <peterdunord@gmail.com>, "public-audio-dev@w3.org" <public-audio-dev@w3.org>
- Message-ID: <CAE3TgXFxjRJXXwyw4tfh7b9KPqR5sXEv+NJ=xZHHTDN4_Q0ntg@mail.gmail.com>
Well, there is https://github.com/WebAudio/web-audio-api/issues/344 with a proposed algorithm on how it should work. On Wed, Mar 2, 2016 at 11:02 AM, Chris Wilson <cwilso@google.com> wrote: > I *do* hear clicks, fwiw. I think this calls out we need the > cancel-and-set-checkpoint ASAP. > > On Wed, Mar 2, 2016 at 10:15 AM, Raymond Toy <rtoy@google.com> wrote: > >> -public-audio >> +public-audio-dev >> >> I don't hear any clicks. >> >> But there are several things I see that might cause clicks. >> >> - gain.gain.value might not be exactly the value you expect because >> it's asynchronous with the audio thread that's doing the automation. >> - cancelScheduledValues doesn't (currently) hold the values so what >> happens after future events are cancelled may not have the value you expect. >> - depending on the state of the main thread and the audio thread, >> setValueAtTime(currentValue, now) may already be in the past from the view >> of the audio thread. That currently means setValueAtTime may not actually >> do anything, which means the linearRamp will start from the last automation >> value. >> >> >> On Wed, Mar 2, 2016 at 2:10 AM, Peter van der Noord < >> peterdunord@gmail.com> wrote: >> >>> I'm somewhat lost about the way AudioParams react to canceling/adjusting >>> while they are currently in a transition. I can't figure out why this >>> example results in clicks in the audio when repeatedly clicking the button: >>> >>> http://codepen.io/anon/pen/xVGwRY >>> >>> I don't see any reason why this should give me clicks, am i doing >>> something wrong here? >>> >>> >>> regards, >>> Peter van der Noord >>> >>> >> >
Received on Thursday, 3 March 2016 17:11:23 UTC