Introduction

If sounds should load asynchronously but still play one after another in order, you need a queue and a single playback coordinator. The coordinator's job is simple: enqueue requests immediately, but start the next sound only when the current one finishes.

Separate Loading From Playback Order

The common mistake is to treat asynchronous loading as permission for overlapping playback. Those are different concerns.

A good design has two parts:

• asynchronous loading or preparation of audio assets
• one serialized playback queue

That way the UI stays responsive, but the user still hears the sounds in order.

Queue-Based Design

A first-in, first-out queue is usually enough.

1class SoundQueue {
2  constructor() {
3    this.queue = [];
4    this.isPlaying = false;
5  }
6
7  enqueue(url) {
8    this.queue.push(url);
9    if (!this.isPlaying) {
10      this.playNext();
11    }
12  }
13
14  async playNext() {
15    if (this.queue.length === 0) {
16      this.isPlaying = false;
17      return;
18    }
19
20    this.isPlaying = true;
21    const url = this.queue.shift();
22    const audio = new Audio(url);
23
24    audio.addEventListener("ended", () => this.playNext(), { once: true });
25    await audio.play();
26  }
27}
28
29const q = new SoundQueue();
30q.enqueue("sound1.mp3");
31q.enqueue("sound2.mp3");
32q.enqueue("sound3.mp3");

Each enqueue call returns immediately, but only one sound plays at a time.

Why This Works

The queue preserves ordering, and the ended event is the trigger that releases the next item.

You do not need to block the main thread while waiting for a sound to finish. You only need a clear rule that says: no new playback starts until the current sound signals completion.

Handling Preloading

If file loading is slow, you can preload audio objects or decoded buffers before enqueueing them. The queue concept stays the same.

1async function preloadAudio(url) {
2  const audio = new Audio(url);
3  audio.preload = "auto";
4  return audio;
5}

Then your queue can hold prepared audio objects instead of raw URLs.

Preventing Overlap and Reentrancy Bugs

The isPlaying flag matters. Without it, two enqueue calls that happen close together may both decide to start playback, which defeats the queue.

The rule should be:

• enqueue is always safe
• playback is started only by the coordinator
• completion triggers the next dequeue

That single-owner pattern keeps the logic predictable.

A More General Pattern

This design is not specific to browser audio. The same idea applies in mobile apps, game engines, and desktop audio systems:

• one queue
• one active item
• one completion callback
• start the next item only from the completion path

The audio API changes, but the queueing logic stays the same.

Useful Extensions

Real systems often add features such as:

• priority sounds that jump ahead in the queue
• cancellation of pending sounds
• separate queues for music and effects
• a maximum queue length to avoid unbounded buildup

Those are extensions to the same core architecture.

Common Pitfalls

A common mistake is starting playback directly in every asynchronous callback. That makes completion order determine playback order, which is often wrong.

Another mistake is forgetting to guard the "already playing" state, which allows accidental overlap.

Developers also often tie the queue to loading completion instead of explicit enqueue order. If preserving request order matters, the queue should own that ordering explicitly.

Summary

• Queue the sound requests immediately, but let only one coordinator start playback.
• Use a single active sound and start the next one on completion.
• Keep asynchronous loading separate from playback order.
• Guard against reentrancy with an isPlaying or equivalent state flag.
• The same queue pattern works across web, mobile, desktop, and game audio APIs.