Web Audio Loop Points: Seconds, Milliseconds or Sample Frames?

The AI-generated cover illustrates headphones and sound. It is not a sampled waveform, loop-point interface, or seamless-playback test.

A two-second effect loops back at the wrong position in a web game. First identify whether the integration expects seconds, milliseconds, or sample frames, then identify the buffer actually being played. Equal numbers in different units are not equal positions.

Identify the specific API

The official MDN loopEnd reference defines the Web Audio property as an offset in seconds, used only when loop is true. A millisecond value or sample-frame index cannot be transferred to that parameter without conversion.

This concerns AudioBufferSourceNode, not every engine, audio middleware, or Tooliva control. Read the actual contract rather than assuming a generator's parameter JSON contains a loopEnd field.

Keep a dimensionally consistent example

Assume exactly two seconds at 48,000 sample frames per second: that is 96,000 sample frames, or 2000 milliseconds of time. For a parameter expecting seconds, 2.0, 2000, and 96000 are not interchangeable.

A sample frame is not the sum of sample values across both stereo channels. More channels do not by themselves double the duration. These are conditional examples, not specifications for Tooliva's default output.

Decoding may change the buffer's sample rate

The official MDN decodeAudioData documentation explains that decoded AudioBuffer data is resampled to the AudioContext's sample rate. A frame index from the original file is therefore not automatically the same frame index in the new buffer.

In an idealized two-second model with the same time origin and content duration, 44,100 frames per second corresponds to 88,200 frames rather than 96,000. Dividing the old 96,000 by the new 44,100 gives about 2.177 seconds: that mixes two different data representations.

Read the actual current buffer properties. The AudioBuffer.duration reference reports PCM duration in seconds; do not infer it from WAV disk bytes. Trimming or changing speed requires further marker checks, beyond a unit conversion.

Verify boundaries before judging the join

• Record the source file and decoded buffer, including actual rate and duration.
• Write down loop start, loop end, their units, and whether looping is enabled.
• Confirm the markers address the current buffer rather than another variant or revision.
• Check the return position at the real playback speed, then listen separately for gaps, abrupt changes, or an unnatural join.

Correct bounds do not guarantee seamless sound. No browser audio experiment was performed for this article, and it offers no universal constants that repair every loop.

Keep the actual variant and exported file from the sound-effects tool before the integrator checks loop configuration. For a size question rather than a position question, use the separate WAV size, sample-rate and channel guide.