Ok, I found the difference: Chrome ever use the duration parameter, Firefox ignores duration parameter at loop sounds. 

I think, this behaivor is wrong and it makes problems by using sound atlases which includes looping sounds.

So, in chrome it is impossible to use sound atlases with looping sounds, only the last sound in a atlas can be a loop sound (with note release) :-(

Don't know what a sound atlas is, but maybe you start by not specifying a duration for the AudioBufferSource that you're playing?

In any case, this is working as required by the spec (https://webaudio.github.io/web-audio-api/#dom-audiobuffersourcenode-start).  The duration parameter to start limits how long the loop actually plays.

Closing as WAI. If this is incorrect, please re-open or file a new bug.

I think there is a lack in w3c definition. There is no description of the duration-parameter behaivor while a loop sound is playing.

A sound atlas is a collection of multiple sounds inside one audio buffer.

The chrome audio api impelementation makes no sense, because there is no additional parameter to define the end sample of the started sound. Firefox uses the duration-parameter to define the end of the sound.

The only workaround for chrome is currently to extract all loop sounds from the atlas to separate audio buffers. But that is not the idea of using sound atlases :-(

For duration, the spec says this:  https://webaudio.github.io/web-audio-api/#dom-audiobuffersourcenode-start.  Pretty much a duration parameter is the same as calling start(now + duration).

And I'm pretty sure this is consistent with the playback algorithm https://webaudio.github.io/web-audio-api/#playback-AudioBufferSourceNode

Can you explain exactly what you think

start(time, offset, duration) should do when you have loop = true, and loopStart and loopEnd set to some value?

Re-opening issue again.

Hi,

W3C: "Setting the loop attribute to true causes playback of the region of the buffer defined by the endpoints loopStart and loopEnd to continue indefinitely,..." (the last word is important)

So, the duration-parameter defines the end sample, not the duration (time) of looping or playing. It is the same as the playbackRate property which is independent of the duration-parameter. Only in this way it is possible to play instrument sounds with sustian and release, independent of playback-rate and looping (especially if there are multiple samples for each note in audio buffer).

And: "Note that the values of the loop endpoints are expressed as time offsets in terms of the sample rate of the buffer, meaning that these values are independent of the node's playbackRate parameter which can vary dynamically during the course of playback."

Regards
Meinolf

I have updated my test case: http://www.oxyd.games/soundtest3.html

Please compare Firefox and Chrome behaivor.

Thanks for the updates.  I think in c#8, the parts you referenced from the spec are bugs in the spec.  I'll file an issue against the spec on that.  I think the description of the duration parameter is the definitive definition of how it works.

And thanks for the update test.  I do hear that Chrome and Firefox produce different sounds for the "Start Laser Loop Sound (1)". I assume you think Firefox is doing the right thing.

Spec issue:  https://github.com/WebAudio/web-audio-api/issues/1387

From the spec issue, Chrome is working as intended.  Specifying a duration implies the loop will eventually stop.  The text will be updated to clarify that loop is stopped if a duration is specified.

A Firefox representative was surprised that duration was not being honored.

Closing as WontFix: WAI.

Please reopen or file a new issue if this is incorrect.