Delays after playing multiple sequential audio files

Question

I am currently developing a walkie-talkie type environment. Recording and resampling audio work fine now (thanks for the help), playing works .. sort of.

My data comes in (WAV-) blobs, so here's what I do:

audioPlay(blob)
{
        var fileReader = new FileReader();
        fileReader.onload = function() {
                theContext.decodeAudioData(this.result, function(buffer) {
                        var source = theContext.createBufferSource(); 
                        source.buffer = buffer;
                        source.connect(theContext.destination);
                        source.start(0);
                        });
                };
        fileReader.readAsArrayBuffer(blob);
}

But every new audio adds a slight start-delay which grows with every new audio. After a few audios, the delay adds almost 2-3 seconds. Logging doesn't show any delays, program flows fine all the way down to .source.start.

Any ideas?

score 0 · Answer 1 · answered Dec 21 '13 at 00:27

0

Don't start your playback at 0 for every sample. Instead track the time.

 if (nextTime == 0) { nextTime = context.currentTime }
 source.start(nextTime);
 nextTime+=source.buffer.duration;

answered Dec 21 '13 at 00:27

Brad.Smith

1,071
3
14
28

Thanks @Brad will try that and report back. Though IMHO it doesn't really make sense, because I create new buffers, and new source.connects - completely independent processes. – Michaela.Merz Dec 21 '13 at 11:07
`audioPlay` has two sequential asynchronous operations inside of it. The `fileReader.onload` event callback is asynchronous, and `decodeAudioData` is asynchronous. You really can't have any expectation of predictable timing this way. That's why calling `source.start(0)` doesn't work. – Kevin Ennis Dec 21 '13 at 14:01
@KevinEnnis I don't follow you. I don't expect any precise or predictable timing. I am assuming, that after onload is done and decodeAudioData is done (the pcm data is available in the buffers and ready to play) playing should commence without delay. We're talking small, independent samples, 100K at the most. Which is exactly how it works for the first sample, adding a tiny fraction of a delay to any following samples - adding up to a second or so after 4 or 5 samples and so on. – Michaela.Merz Dec 21 '13 at 15:09
start(0) and start(context.currentTime) are semantically equivalent. – cwilso Dec 23 '13 at 14:49

score 0 · Answer 2 · answered Dec 23 '13 at 14:50

Michaela, this sounds more like it might be a problem in the source - are you sure each incoming blob is correct (of correct length, and has audio at the beginning?) It seems like it might be that you're just tacking the new recording on to the end of an empty buffer at that end. Barring that specific problem, I'd take a look at the audio blob that's coming in - maybe the decode is too expensive for some reasons? (I.e. if you have a 2-3 second cumulative delay, you should be able to tell from logging if the delay is in receiving the data, decoding it, or in the buffer itself.

I looked at that. Each audio played independently starts right away (after a page reload), logging shows now delays - is a mystery :) But one, I am going so solve :D — Michaela.Merz, Dec 23 '13 at 22:09

Delays after playing multiple sequential audio files

2 Answers2