Bug 92875 – exponentialRampToValue produces 0 after 512 sec

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Web Audio

[Raymond Toy]

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.

[Miguel]

By the way, I also noticed that setting a gain of value 0 does not work, despite the specification "The nominal minValue is 0".

[Raymond Toy]

(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.

[Miguel]

(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.

[Raymond Toy]

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?

[Raymond Toy]

Updating summary to reflect what's really going on.

[Raymond Toy]

(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.

[Raymond Toy]

(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.

[Miguel]

(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 ?

[Chris Rogers]

(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...

[Miguel]

(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);

[Raymond Toy]

Closing this bug since the test uses features that are no longer part of the WebAudio API.