[Webkit-unassigned] [Bug 92875] exponentialRampToValue produces 0 after 512 sec

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=92875





--- Comment #9 from Chris Rogers <crogers at google.com>  2012-08-10 15:57:19 PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> > > > Updating summary to reflect what's really going on.
> > > 
> > > It's not just the exponential ramp; the linear ramp shows the same issues.  More investigation needed.
> > 
> > This seems to be related to the gain attribute in the AudioBufferSourceNode.  If an AudioGainNode is used instead, audio continues for at least 600 sec.  There are some audio artifacts, but that might be due to using setInterval to play audio.
> > 
> > Since the latest version of the spec (http://www.w3.org/TR/2012/WD-webaudio-20120802/) no longer has a gain attribute in an AudioBufferSourceNode, the test uses an incorrect method now.
> > 
> > Perhaps this issue should be closed now.
> 
> I didn't performed a test with an AudioGainNode, but if it works, I'm ok with that. The point that I don't get is related to the SetInterval method. Why should this produce glitches ? I used a delay of 1ms in my test in order to avoid a call to noteOn with a time value < present time. Perhaps is this delay too small in some cases (e.g. Garbage collection). Anyway, it would be nice to know how to handle such a situation, I believe 16ms should be ok in all cases, as it's the time it takes to render a frame at 60 FPS.
> What do you think is the best practice ?

I would recommend scheduling events further into the future greater than 16ms to make things more resilient.  100ms is safer.
I haven't had a chance to look specifically into your code, but for sequencer type applications, drum-machines, etc., you want to schedule further into the future, because the next time you have a chance to schedule might be longer than a 16ms interval.  Garbage collection itself can take longer than this, among other things.

Hope that helps...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.