When calling start on an AudioBufferSourceNode with the context's currentTime, it seems that this parameter is treated as relative and it will start currentTime seconds in the future. This contradicts the specification[1], which says that the 'when' parameter is in the same coordinate system as currentTime, and that any time less than currentTime indicates immediate start, which strongly infers that calling start with currentTime is equivalent to calling start with 0. In my testing, calling start with the context's currentTime causes the sound to play approximately currentTime seconds in the future. [1] https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#methodsandparams-AudioBufferSourceNode I haven't quite figured out how 'stop' interprets its 'when' parameter, but I've not managed to get it to behave in any consistent way :(

This plays as expected for me, with pulseaudio. Does each button start a tone more or less immediately on your system?

(In reply to Karl Tomlinson (:karlt) from comment #1) > Created attachment 8355965 [details] > testcase > > This plays as expected for me, with pulseaudio. > > Does each button start a tone more or less immediately on your system? This is odd, your example works, but my code does not. My code works correctly in Chrome. Perhaps because my buffers are created from oggs? I'll see if I can make a small test-case.

Also worth noting, I'm using looping audio when I experience this problem, that also may affect results.

(In reply to Chris Lord [:cwiiis] from comment #3) > Also worth noting, I'm using looping audio when I experience this problem, > that also may affect results. disregard this, I see you are in your code too.

This is attachment #8355965 [details], modified slightly to better represent how I'm using web audio, that exhibits the error I mention.

It seems the issue is that the source's treatment of currentTime is frozen to its creation time? Chrome behaves correctly in this situation.

Changing bug title to better describe the bug.

It's as if (time_of_start_call - time_of_node_creation) is added to the |when| parameters.

Another note, even employing the work-around of not creating the source until it's needed, I'm getting odd treatments of 'when' on Android Nightly (but working fine in Android release). I've yet to pinpoint what this issue is, but if it's sufficiently different, I'll file a new bug for it.

Is this WebKit bug relevant here? https://bugs.webkit.org/show_bug.cgi?id=114923

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #10) > Is this WebKit bug relevant here? > https://bugs.webkit.org/show_bug.cgi?id=114923 No, I don't think so.

Karl -- This sounds like a high P2 to me, but if you and/or Paul think this is an important use case (especially for games), please re-prioritize higher. Thanks.

Fixed in https://hg.mozilla.org/mozilla-central/rev/0279107b81d3

Here is a Mochitest test case that tests for this bug.