Bug 92875 - exponentialRampToValue produces 0 after 512 sec
Summary: exponentialRampToValue produces 0 after 512 sec
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Audio (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-01 09:33 PDT by Raymond Toy
Modified: 2012-08-13 14:12 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raymond Toy 2012-08-01 09:33:06 PDT
See the simplified test, https://bugs.webkit.org/attachment.cgi?id=155816, in https://bugs.webkit.org/show_bug.cgi?id=92686.

Audio will play for about 512 sec, and then it suddenly changes.  Some audio is still playing but it is faint and sounds more like a click.
Comment 1 Miguel 2012-08-01 09:44:31 PDT
By the way, I also noticed that setting a gain of value 0 does not work, despite the specification "The nominal minValue is 0".
Comment 2 Raymond Toy 2012-08-01 09:56:24 PDT
(In reply to comment #1)
> By the way, I also noticed that setting a gain of value 0 does not work, despite the specification "The nominal minValue is 0".

Check the latest spec, which says that an error is thrown if the value is less than or equal to zero.  This is a consequence of the formula used for the exponential ramp.
Comment 3 Miguel 2012-08-01 10:05:22 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > By the way, I also noticed that setting a gain of value 0 does not work, despite the specification "The nominal minValue is 0".
> 
> Check the latest spec, which says that an error is thrown if the value is less than or equal to zero.  This is a consequence of the formula used for the exponential ramp.

Ok, thanks for the info.
Comment 4 Raymond Toy 2012-08-02 10:07:13 PDT
http://www.corp.google.com/~rtoy/bugs/webkit/92686/test.html (google internal) demonstrates the problem.  It's based on the simplified test, but uses a constant 1 as the signal.  So we get nice exponential ramps starting at every second and decaying quickly to zero.  But the ramps suddenly stop after time 511; ramps at 512 and later are gone.  Also note that the peaks only reach to about 0.7.  I was expecting the peak to be 1.  And the first peak at time 0 does have a value of 1.

I wonder if these issues are not related to bug https://bugs.webkit.org/show_bug.cgi?id=76919?
Comment 5 Raymond Toy 2012-08-02 10:08:48 PDT
Updating summary to reflect what's really going on.
Comment 6 Raymond Toy 2012-08-07 16:38:36 PDT
(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.
Comment 7 Raymond Toy 2012-08-08 16:30:15 PDT
(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.
Comment 8 Miguel 2012-08-10 15:52:29 PDT
(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 ?
Comment 9 Chris Rogers 2012-08-10 15:57:19 PDT
(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...
Comment 10 Miguel 2012-08-11 03:51:24 PDT
(In reply to comment #9)
> (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...

That helps, thank you. My code looked something like this :
function play() {
 t = audioContext.currentTime + .001;
 ...
 noteOn(t);
}
setInterval(play, 125);
Comment 11 Raymond Toy 2012-08-13 14:12:03 PDT
Closing this bug since the test uses features that are no longer part of the WebAudio API.