Currently, AudioContext.currentTime returns a "snapshot" of the current time of the context's destination stream on the main thread. This creates problems when currentTime is used to schedule automation events. See the attached testcase for example. What that testcase does is it schedules two automation events, one at currentTime and one at currentTime+5, but the result should be that the gain value should be 0 at all times. In Chrome, the test case produces silence, but in Firefox, it produces about 3000 non-zero frames at the start, which is basically the result of the stream's current time on the audio thread running ahead of the stream's current time on the main thread, therefore the mTime values of the first AudioTimelineEvent is never zero. I think the right fix for this issue is to save the value of the current time of the destination stream on the main thread every time an AudioParam is modified, then use that value in WebAudioUtils::ConvertAudioParamToTicks to calculate a compensation offset when we're converting the AudioParam values from times to ticks. One problem with this solution is that we would need to do this kind of compensation everywhere we're dealing with absolute time values based on AudioContext.currentTime, off the top of my head, that includes AudioParam and AudioBufferSourceNode::Start/Stop, so maybe it's not that bad? Can you guys think of a better solution?

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #0) > I think the right fix for this issue is to save the value of the current > time of the destination stream on the main thread every time an AudioParam > is modified, then use that value in WebAudioUtils::ConvertAudioParamToTicks > to calculate a compensation offset when we're converting the AudioParam > values from times to ticks. That doesn't sound like the right solution to me. For example this code: gain.gain.setValueAtTime(0, ctx.currentTime); gain.gain.setTargetAtTime(0, ctx.currentTime + 5, 1); would then mean the gain is 0 for longer than 5000ms, which is counterintuitive (even though it's what Webkit does).

(In reply to comment #1) > (In reply to :Ehsan Akhgari (needinfo? me!) from comment #0) > > I think the right fix for this issue is to save the value of the current > > time of the destination stream on the main thread every time an AudioParam > > is modified, then use that value in WebAudioUtils::ConvertAudioParamToTicks > > to calculate a compensation offset when we're converting the AudioParam > > values from times to ticks. > > That doesn't sound like the right solution to me. For example this code: > gain.gain.setValueAtTime(0, ctx.currentTime); > gain.gain.setTargetAtTime(0, ctx.currentTime + 5, 1); > would then mean the gain is 0 for longer than 5000ms, which is counterintuitive > (even though it's what Webkit does). Hmm, I'm not sure what you mean. Note that the interesting part of my test case is the setValueAtTime call using ctx.currentTime, not setTargetAtTime. (I'm basically using the latter to shut up all playback in an implementation which doesn't have this bug. What currently happens in Firefox is that the Gecko is that the first event (setValueAtTime) gets scheduled at tick 3000, let's say, as opposed to 0, and when we start to play back the buffer, for the first 3000 frames, we just take the default value of the gain node, which is 1.0, and as soon as we hit frame 3001, we take the automation event value (0.0), which causes the short burst of non-zero frames the the very beginning.

This implements the approach that roc and I talked about on IRC. It seems to work fine.

Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.