SFX Plays Once, Then start() Fails? Reuse the Buffer, Not the Source Node

The first trigger works, but a second call throws InvalidStateError. Before generating a different sound, determine whether both calls start the same AudioBufferSourceNode. The reusable asset and the lifetime of its playback object are separate concerns.

Identify the real error and API first

Keep the file, first and second trigger steps, error name and actual call site. Without a trace, record the cause as unconfirmed. A silent second trigger is not automatically InvalidStateError, and media elements or engine-specific audio APIs do not inherit every Web Audio node rule.

If the first attempt is already silent, start with the separate guide to playback permission and same-file auditioning. This article addresses an identified buffer-source lifecycle; it does not assert that Tooliva currently has this fault.

The source is single-use; the audio data is reusable

The MDN AudioBufferSourceNode reference states that a source can be played only once, while the AudioBuffer can be reused for multiple plays. Its start() reference identifies a repeated start on the same node as an InvalidStateError condition.

Stopping a source, reaching the end or clicking again does not turn that used node into a new unstarted source. Ask the integration owner to verify object identity rather than inferring it from the filename.

Separate shared data from each playback instance

1. Retain the decoded AudioBuffer for the intended file.
2. Create a new AudioBufferSourceNode for the next playback and assign that buffer.
3. Connect it through the project's real routing, including any required gain or effect chain.
4. Call start once on that new source, with explicit handling for cancellation, completion and retained references.

These are responsibilities, not a complete production player. They do not require a new AudioContext on every click or repeated downloads, decoding and sound generation. Cache and resource lifetimes still need the receiving application's policy.

Decide whether repeated triggers should overlap

Creating independent sources can allow simultaneous playback. If the design permits only one UI notification, the player owner needs an explicit rule for stopping the old instance or limiting active sources. A successful second sound does not validate rapid repeated input.

Keeping only the latest sound is not universally correct either: firing, ambience and UI feedback have different requirements. No loudness, clipping or latency measurements were performed here, and no fixed voice count is promised for every device.

Accept the integration with one unchanged export

Keep the selected variant and export name from Tooliva's SFX tool and use that same WAV for the receiving project's tests. A successful source audition does not establish correct node management in the game.

Cover the first play, replay after completion, retrigger during playback and rapid input. Record source identity and the intended stop policy. If the issue remains, inspect the actual output chain and context state before changing the asset under comparison.