The current plan is to fix bug 449157 in such a way that the looping is seamless. I'm not sure it's feasible to provide (or, at least, guarantee) seamless looping when script sets currentTime to the start of the media.
Great, thanks for taking that into account. I'm just wondering: is there any technical difference in setting 'loop' to true or giving a 'currentTime = 0' on an ended event? Seems the same to me...
There are, I forgot to mention them earlier. One is that the loop attribute allows the decoder to know in advance that the media is looping, so it can prepare to handle that by not tearing down resources at the end of playback (such as the decode threads, audio device, etc.) The second is that your example sets currentTime in an ended event handler. The ended event is dispatched after playback ends, which is dispatched after we have drained and closed the audio device. The event handler runs asynchronously on the main thread, so (in addition to the tearing down resources issue mentioned above) there is some delay between playback ending where the event is dispatched and the time the event handler runs. To allow seamless looping, the ended event would need be to be dispatched early enough that the event handler would set currentTime at the correct moment, which given the indeterminate delays between the event dispatch and event handler running, isn't really possible. Having said that, there are probably improvements that can be made to reduce the delay between dispatching the ended event and starting playback again. It's just that it's not possible to guarantee anything close to seamless looping without the loop attribute.
(In reply to comment #3) > It's just that it's not possible to guarantee anything close to seamless > looping without the loop attribute. Note also that when using lossy compression (such as Vorbis), even if the first sample of the file immediately follows the last, there may be glitches caused by differing quantization used on the two blocks. For truly seamless looping, you want to crosslap the end of the file with the beginning using the MDCT windows, which may require specially prepared files for best results (see http://xiph.org/vorbis/doc/vorbisfile/crosslap.html for details). This is something I expect would be done if the loop attribute is present, but may not be the behavior you would want on a normal seek.
Based on comment 1 I think it would be safe to add a dependency to bug 449157 or dupe it.
Reopening this to track seamless looping. Bug 449157 now tracks basic (non-seamless) looping support.
This still seems to be an issue on Linux at least.
(In reply to Alexander Brüning from comment #9) > This still seems to be an issue on Linux at least. No patches have landed to resolve this issue yet.
Created attachment 8423887 [details] loop.tar.gz Web Audio API is perfectly suitable for this, see the attached demo (unzip, untar and run loop.html, the audio sample is included). I threw in a play/pause button, as it seemed to be a needed feature. Note that you can put any codec that works in <audio> in the decodeAudioData call, it'll get decoded for you by the Web Audio API. Jukka, does that work for you?
Thanks, I downloaded the file, but I wonder if it has the wrong file? It did not contain a file loop.html.
Created attachment 8423890 [details] loop.tar.gz Oops, went too fast, this has the right files.
Perfect, that workaround is working great! Thanks Paul!
Testing more, I am hitting this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1012801 How difficult would this bug be to fix? (I expect between this and 1012801, this bug would be the easier one to tackle?) I seem to be trading bugs now when trying to find a workaround.
Moving this to backlog. This is too late to take in 1.4
Note: For games we need either this bug fixed or Bug 1012801 to be able to do seamlessly looping audio. Likely target is 2.0.
Looking back at this, currently in order to play back looping audio clips, one can 1. decodeAudioData() the whole clip up front, and play it as a looping audio buffer with WebAudio (AudioBufferSourceNode.loop=true), which will be seamless 2. Emscripten compile Ogg Vorbis and implement the asset decoding and streaming manually in a looping manner The first one is good solution if the sound clip is really short so that decodeAudioData() will take very little time and very little memory. The second solution is often used in asm.js compiled games to keep the performance good and memory footprint low. Can Web Audio API produce seamlessly looping audio while decoding on demand? I.e. not having to do decodeAudioData() of the whole clip? When Paul posted comment 14, I believe it was not possible then, but that was some time ago - what is the situation today? In any case, marking as games:p3 for now, given that we do have options 1. and 2. that solve the most common cases.
(In reply to Jukka Jylänki from comment #19) > 2. Emscripten compile Ogg Vorbis and implement the asset decoding and > streaming manually in a looping manner Not sure exactly how this handles seemless looping, but perhaps MSE could be used to manually streaming the encoded data, if that can be looped. > Can Web Audio API produce seamlessly looping audio while decoding on demand? Only through MediaElementAudioSourceNode, if a media element can play the looping audio. Or maybe the assets can be broken in parts for the client to pass to decodeAudioData() shortly before required.
Yes, what karlt said, the situation has not changed much on the Web Audio API front.
(In reply to Karl Tomlinson (ni?:karlt) from comment #20) > (In reply to Jukka Jylänki from comment #19) > > Can Web Audio API produce seamlessly looping audio while decoding on demand? > > Only through MediaElementAudioSourceNode, if a media element can play the > looping audio. Can you elaborate on this a bit? See the testcase audio_loop.html in comment 11: > <html><head></head> > <body> > <audio id='a' src="noise.ogg" loop="true" /> </audio> > <p>Pressing play should generate seamlessly joined audio playback (modulo any potential snapping occurring from issues with the authored audio): > <p><b>TECHNIQUE 1: The audio.loop="true" property.</b> > <input type="button" onclick="document.getElementById('a').play();" value="PLAY"> > </body> > </html> That does not currently produce seamlessly looping audio. Is the playback technically any different if this <audio> element was wrapped to a MediaElementAudioSourceNode in WebAudio graph, or will the audio output result (codepath) be the same?
(In reply to Jukka Jylänki from comment #22) > Is the playback > technically any different if this <audio> element was wrapped to a > MediaElementAudioSourceNode in WebAudio graph, or will the audio output > result (codepath) be the same? The output is the same. MediaElementAudioSourceNode is only useful for looping if a media element can do that. The only way it currently might be able to do that would be if the encoded data could be continually streamed into a MediaSource buffer.