Audio V2: Resume() audio sprites not working

a_bolog · July 5, 2026, 1:40pm

I noticed that resume() doesn’t resume from the same playback time when it was paused(), if loopStart or loopEnd is set.

It instead always plays from the loopStart playback time value, and not from when it was paused.

Playground: https://playground.babylonjs.com/#6FZCRD#1

This also happens with Sound Buffers.

I basically want to create multiple sound sprites from one buffer, each with unique startOffset, loopStart, loopEnd, and be able to pause resume them individually like normal sounds.

@RaananW

RaananW · July 6, 2026, 2:26pm

verified, most certainly a bug. let me look into that.

RaananW · July 6, 2026, 4:31pm

github.com/BabylonJS/Babylon.js

fix(AudioV2): resume looping static sound from correct position with loopStart/loopEnd (#18661)

master ← raananw-fantastic-robot

opened 04:19PM - 06 Jul 26 UTC

RaananW

+44 -2

## Problem When an AudioV2 static sound with a loop sub-range (`loopStart` / `l…oopEnd`) is paused and then resumed, playback always restarts at `loopStart` instead of continuing from where it was paused. Reported on the forum: [Audio v2 resume audio sprites not working](https://forum.babylonjs.com/t/audio-v2-resume-audio-sprites-not-working/63743). This also affects the "audio sprite" use case (multiple sounds sharing one buffer, each with its own `startOffset` / `loopStart` / `loopEnd`). Repro playground: https://playground.babylonjs.com/#6FZCRD#1 ## Root cause In `_WebAudioStaticSoundInstance.play()`, the resume offset was computed as: ```ts startOffset += this._enginePauseTime; startOffset %= this._sound.buffer.duration; ``` This wraps against the whole buffer duration and ignores the loop region. When `loopStart`/`loopEnd` describe a sub-range, the computed offset can fall outside `[loopStart, loopEnd)`, so the underlying `AudioBufferSourceNode` (which is looping) restarts playback at `loopStart`. ## Fix When resuming a looping sound, map the elapsed playback time onto the actual loop region: play the initial `startOffset → loopEnd` segment, then wrap the remaining time within `[loopStart, loopEnd)`. Non-looping behavior is unchanged. The loop bounds are validated the same way Web Audio treats them (falling back to the full buffer when `loopStart`/`loopEnd` don't describe a valid sub-range). ## Testing - Added regression test `Play looping sound with loopStart and loopEnd options set, pause it, and resume it` to `staticSound.playback.test.ts`. - Verified the new test **passes with** the fix and **fails without** it (produces `[1, 2, 1, 1, 2]` instead of the expected `[1, 2, 1, 2, 1]`), so it genuinely guards the regression. - All 43 existing static-sound playback + currentTime Playwright tests pass, including existing pause/resume and loop cases. Note: streaming sounds use a separate backend and are out of scope here; buffer-backed sounds go through this same static-sound instance path and are covered.

a_bolog · July 7, 2026, 2:15pm

@RaananW

Thanks it’s working now.
I’ve notice another bug I’m gonna write it here:

I’ve modified the sound file, it’s now the first 5 seconds merged 3 times.
To simulate 3 identical audio sprites in one file.

Now press Play, then press Sprite 1, 2, 3. It jumps perfectly in sync. Works as expected.
Then press Pause then Resume, now everything is broken.
Example Playground: https://playground.babylonjs.com/#6FZCRD#2

Not sure if this is the problem, but setting loopStart and loopEnd while the sound is playing, does not propagate, unlike pitch and playbackRate

Something like adding loopStart, loopEnd setters on _WebAudioStaticSoundInstance that directly write to the live AudioBufferSourceNode:

public set loopStart(value: number) {  
    this._options.loopStart = value;  
    // missing: iterate instances and call instance.loopStart = value  
}

public set loopStart(value: number) {  
    if (this.\_sourceNode) this.\_sourceNode.loopStart = value;  
}

github.com/BabylonJS/Babylon.js

packages/dev/core/src/AudioV2/abstractAudio/staticSound.ts

6073e1c49


      
          }
          
          /**
           * The start of the loop range, in seconds. Defaults to `0`.
           * - If less than or equal to `0`, the loop starts at the beginning of the sound.
           */
          public get loopStart(): number {
              return this._options.loopStart;
          }
          
          public set loopStart(value: number) {
              this._options.loopStart = value;
          }
          
          /**
           * The end of the loop range, in seconds. Defaults to `0`.
           * - If less than or equal to `0`, the loop plays for the sound's full duration.
           */
          public get loopEnd(): number {
              return this._options.loopEnd;
          }

RaananW · July 7, 2026, 6:32pm

i’ll look into that

RaananW · July 8, 2026, 10:18am

github.com/BabylonJS/Babylon.js

fix(AudioV2): propagate live loopStart/loopEnd changes to playing static sounds (#18669)

master ← raananw-audio-v2-live-loop-range

opened 10:16AM - 08 Jul 26 UTC

RaananW

+52 -0

## Problem Setting `loopStart` or `loopEnd` on an AudioV2 `StaticSound` while t…he sound is already playing had no audible effect — the live loop region stayed at whatever it was when playback started, until the sound was stopped and replayed. This is inconsistent with `pitch` and `playbackRate`, which already propagate to playing instances. This breaks the audio-sprite use case (one shared buffer, hopping between regions by changing the loop range on the fly). Reported on the forum: [Audio v2 resume audio sprites not working](https://forum.babylonjs.com/t/audio-v2-resume-audio-sprites-not-working/63743/4). ## Root cause `StaticSound.loopStart` / `loopEnd` setters only wrote to `_options`: ```ts public set loopStart(value: number) { this._options.loopStart = value; // stops here — never reaches the playing instance } ``` The live `AudioBufferSourceNode.loopStart` / `loopEnd` were only ever set once, inside `_initSourceNode()` at play time. There was no instance-level setter at all, unlike `pitch` / `playbackRate` which iterate `_instances` and push the value onto the running node. ## Fix Mirror the existing `pitch` / `playbackRate` propagation pattern: - **`staticSoundInstance.ts`** — declare abstract `loopStart` / `loopEnd` instance setters. - **`webAudioStaticSound.ts`** — implement them to write directly to the live `AudioBufferSourceNode` (the same raw assignment `_initSourceNode` already uses), guarded by a null check. Unlike pitch/playbackRate these are plain properties (not `AudioParam`s), so it's a direct write, not a ramped `setTargetValue`. `_options` is still updated so the pause/resume offset math (which reads `_options.loopStart/loopEnd`) stays consistent. - **`staticSound.ts`** — iterate `_instances` and forward the value, exactly like `pitch`. ## Impact on regular scenes No behavioral change for the common cases: setting the loop range before `play()` (already applied at play time), never touching the loop range, and non-looping sounds are all unaffected. The only case that changes is assigning `loopStart`/`loopEnd` *during* playback, which was previously a silent no-op and now works as expected. Cost is negligible — a plain property write per live instance (usually 0–1). ## Testing - Added regression test **"Change `loopStart` and `loopEnd` while a looping sound is playing"** to `staticSound.playback.test.ts`. It plays the `[1, 2)` loop region, switches it to `[2, 3)` mid-playback, and expects `[1, 2, 2, 3, 3]`. - Verified the new test **passes with** the fix and **fails without** it (produces `[1, 2, 2, 3, 2]` — the live loop never moves to group 3), so it genuinely guards the regression. - Full 33-test `staticSound.playback` suite passes, including the existing loop and pause/resume cases. - `tsc -b` on core and ESLint/Prettier on the changed files are clean. Note: streaming sounds use a separate backend and are out of scope here; buffer-backed sounds go through this same static-sound instance path.

a_bolog · July 8, 2026, 12:39pm

@RaananW

Very nice.

I still notice it goes out of sync when setting currentTime after Pause.

I think there is another bug somewhere else.

Here’s a much simpler playground, just a button which skips to 6.0s.

https://playground.babylonjs.com/#6FZCRD#3

Press Play, then press currentTime = 6.0, works perfectly every time. deviation 0.
Now Pause Resume, then skipping deviation is not 0, unless sound is Stopped.

I don’t understand what is happening, I am simply setting the exact same currentTime.

But because of this, when changing the active sprite of a paused/resumed sound, it goes out of sync.

Topic		Replies	Views
Pausing and playing an audio with offset restarts it from the beginning instead of the current position Bugs audio	22	2710	January 28, 2023
AudioV2: Play over paused with new options? Bugs	3	71	June 22, 2026
Sound currentTime exceeds total duration in some cases Bugs audio	2	710	January 27, 2023
scene.audioEnabled skips parts of sounds Bugs	3	476	August 15, 2019
Sound currentTime Questions audio	5	466	January 13, 2023

Audio V2: Resume() audio sprites not working

Related topics