The version that stuck is one class under a hundred lines, types included, sitting on a six-function adapter. What changes from game to game is the bus underneath the engine and the lifecycle that starts and stops it, so those two seams are what this post is about.

Why Howler?

You could go straight to AudioContext and hand-roll everything. I’ve done it, and I don’t recommend it.

For ambience work, Howler (opens in a new tab) is the right tradeoff. It handles cross-browser autoplay and gives you per-instance volume, pan, rate and fade, with sprites if you want them, in about 7 KB gzipped. It wraps Web Audio, so you keep the graph and stop writing the boilerplate.

Everything below assumes Howler, but the bus adapter is the seam: swap in raw Web Audio later and the engine doesn’t change. The demos on this page prove it, because they run the engine class below, unmodified, over a small Web Audio adapter.

The def

A scene is one bed and any number of emitters, and each emitter has a pool of samples and a random range for every knob.

export type Range = [min: number, max: number];

export interface EmitterDef {
  samples: string[];
  intervalMs: Range;
  volume: Range;
  pan: Range;
  rate: Range;
}

export interface SoundscapeDef {
  bed: { sample: string; volume: number; fadeInMs?: number };
  emitters: EmitterDef[];
  maxConcurrentEmitterInstances?: number;
}

rate is what Part 1 called the pitch knob. Howler’s API calls it rate, so the def follows the API.

Here’s the café from Part 1.

export const CAFE: SoundscapeDef = {
  bed: { sample: "restaurant-bed-light", volume: 0.9, fadeInMs: 800 },
  emitters: [
    {
      samples: ["cups-clanging", "cash-register", "espresso-machine"],
      intervalMs: [3000, 8000],
      volume: [0.25, 0.45],
      pan: [-0.5, 0.5],
      rate: [0.95, 1.05],
    },
    {
      samples: ["phone-ringing"],
      intervalMs: [12000, 25000],
      volume: [0.1, 0.18],
      pan: [-0.4, 0.4],
      rate: [0.98, 1.02],
    },
  ],
  maxConcurrentEmitterInstances: 3,
};

The counter pool has three samples and a tight interval, squeezed to a demo timescale (a real café breathes slower). The phone has one sample and rings rarely, quiet and off to one side.

That’s the whole tuning surface. You can change how a scene feels without touching engine code, which is exactly what you want when a sound designer is sitting next to you.

This def is live, so play with it:

An interactive demo goes here. Open the post to try it.

The adapter

The engine never calls Howler. It calls a bus adapter, and that’s what makes it pluggable.

export interface BusAdapter {
  playBed(name: string, opts: { volume: number; fadeInMs?: number }): number | null;

  playEmitter(
    name: string,
    opts: {
      volume: number;
      pan: number;
      rate: number;
      onEnd?: () => void;
    },
  ): number | null;

  stopBed(id: number, fadeOutMs?: number): void;
  stopAll(): void;

  duck(): void;
  unduck(): void;
}

Anything that satisfies those six functions can host the engine. I know that’s suspiciously small for something called a mixer; the first time I wrote this contract, I deleted half of it twice before I trusted that it was enough.

Want a single ambience bus with a global duck multiplier? Implement it that way. Want a full master, music, ambience and SFX mixer? Implement duck() as a category gain change. The engine doesn’t care either way.

The adapter is the only part that should change when the audio setup changes, and the host binding is the only part that changes when the framework does. The engine in the middle stays put.

A minimal Howler adapter

The simplest adapter is one ambience gain, a duck multiplier, and a map of preloaded Howls keyed by name.

import { Howl } from "howler";

const AMBIENCE_BASE_VOLUME = 1.0;
const DUCK_MULTIPLIER = 0.25;
const DUCK_FADE_MS = 300;

export function createSingleBusAdapter(samples: Record<string, string>): BusAdapter {
  const howls = new Map<string, Howl>();
  for (const [name, src] of Object.entries(samples)) {
    howls.set(name, new Howl({ src: [src], preload: true }));
  }

  let ambienceMultiplier = 1.0;
  const liveBeds = new Set<{ howl: Howl; id: number; baseVolume: number }>();
  const liveEmitters = new Set<{ howl: Howl; id: number }>();

  function effectiveVolume(base: number) {
    return base * AMBIENCE_BASE_VOLUME * ambienceMultiplier;
  }

  return {
    playBed(name, { volume, fadeInMs }) {
      const howl = howls.get(name);
      if (!howl) return null;
      const id = howl.play();
      howl.loop(true, id);
      const target = effectiveVolume(volume);
      if (fadeInMs) {
        howl.volume(0, id);
        howl.fade(0, target, fadeInMs, id);
      } else {
        howl.volume(target, id);
      }
      liveBeds.add({ howl, id, baseVolume: volume });
      return id;
    },

    playEmitter(name, { volume, pan, rate, onEnd }) {
      const howl = howls.get(name);
      if (!howl) return null;
      const id = howl.play();
      howl.volume(effectiveVolume(volume), id);
      howl.stereo(pan, id);
      howl.rate(rate, id);
      const entry = { howl, id };
      liveEmitters.add(entry);
      howl.once(
        "end",
        () => {
          liveEmitters.delete(entry);
          onEnd?.();
        },
        id,
      );
      return id;
    },

    stopBed(id, fadeOutMs = 500) {
      for (const entry of liveBeds) {
        if (entry.id !== id) continue;
        entry.howl.once("fade", () => entry.howl.stop(id), id);
        entry.howl.fade(entry.howl.volume(id) as number, 0, fadeOutMs, id);
        liveBeds.delete(entry);
        return;
      }
    },

    stopAll() {
      for (const { howl, id } of liveBeds) howl.stop(id);
      for (const { howl, id } of liveEmitters) howl.stop(id);
      liveBeds.clear();
      liveEmitters.clear();
    },

    duck() {
      ambienceMultiplier = DUCK_MULTIPLIER;
      for (const { howl, id, baseVolume } of liveBeds) {
        howl.fade(howl.volume(id) as number, effectiveVolume(baseVolume), DUCK_FADE_MS, id);
      }
    },

    unduck() {
      ambienceMultiplier = 1.0;
      for (const { howl, id, baseVolume } of liveBeds) {
        howl.fade(howl.volume(id) as number, effectiveVolume(baseVolume), DUCK_FADE_MS, id);
      }
    },
  };
}

This adapter ducks ambience while voice-over plays, which is all most projects need. The multi-bus version has the same shape with one more layer of multiplication; there’s a comparison table after the host bindings.

There’s one gap. duck() only fades the live beds, so an emitter that’s already mid-flight rides through the duck at full volume. Emitters are short, and anything that fires during the duck spawns at the ducked level, so the room still drops. If a two-second espresso clip stepping on your VO bothers you, track the live emitters with their base volumes (the set is already there) and fade them the same way.

The Soundscape class

Given a SoundscapeDef and a BusAdapter, the class owns the bed instance, the emitter timers and the live emitter count. It doesn’t know what Howler is, or React, or anything else about its host.

function pickInRange([min, max]: Range) {
  return min + Math.random() * (max - min);
}

function pickSampleExcluding(samples: string[], last: string | null) {
  if (samples.length === 1) return samples[0]!;
  let next = samples[Math.floor(Math.random() * samples.length)]!;
  while (next === last) {
    next = samples[Math.floor(Math.random() * samples.length)]!;
  }
  return next;
}

export class Soundscape {
  private bedId: number | null = null;
  private timers = new Set<ReturnType<typeof setTimeout>>();
  private liveEmitters = 0;
  private lastPicked = new Map<EmitterDef, string>();
  private disposed = false;

  constructor(
    private readonly def: SoundscapeDef,
    private readonly bus: BusAdapter,
  ) {}

  start() {
    if (this.disposed) return;
    this.bedId = this.bus.playBed(this.def.bed.sample, {
      volume: this.def.bed.volume,
      fadeInMs: this.def.bed.fadeInMs ?? 500,
    });
    for (const emitter of this.def.emitters) {
      this.scheduleNext(emitter);
    }
  }

  private scheduleNext(emitter: EmitterDef) {
    if (this.disposed) return;
    const delay = pickInRange(emitter.intervalMs);
    const timer = setTimeout(() => {
      this.timers.delete(timer);
      this.fireEmitter(emitter);
    }, delay);
    this.timers.add(timer);
  }

  private fireEmitter(emitter: EmitterDef) {
    if (this.disposed) return;
    const cap = this.def.maxConcurrentEmitterInstances ?? 4;
    if (this.liveEmitters >= cap) {
      this.scheduleNext(emitter);
      return;
    }
    const last = this.lastPicked.get(emitter) ?? null;
    const sample = pickSampleExcluding(emitter.samples, last);
    this.lastPicked.set(emitter, sample);

    this.liveEmitters++;
    this.bus.playEmitter(sample, {
      volume: pickInRange(emitter.volume),
      pan: pickInRange(emitter.pan),
      rate: pickInRange(emitter.rate),
      onEnd: () => {
        this.liveEmitters = Math.max(0, this.liveEmitters - 1);
      },
    });
    this.scheduleNext(emitter);
  }

  dispose() {
    if (this.disposed) return;
    this.disposed = true;
    for (const t of this.timers) clearTimeout(t);
    this.timers.clear();
    // stopBed first: the adapter unregisters the bed and starts its fade.
    // stopAll is then the hard kill for whatever is still live (the emitters).
    if (this.bedId !== null) this.bus.stopBed(this.bedId, 500);
    this.bus.stopAll();
  }
}

That’s the whole engine.

The only nontrivial bit is the scheduleNext → fireEmitter → scheduleNext recursion. Each emitter is a metronome that re-arms itself: fire, pick a new random interval, set a fresh setTimeout, and go again.

The disposed flag is the kill switch. Without it, a late timer from the old scene calls bus.playEmitter on a bus that’s already moved on, and you get a ghost bird two seconds into the next level.

Why a flag instead of just clearing the timers?

React StrictMode, and any host that tears down and rebuilds in the same tick, will dispose while a timer is mid-fire. By the time clearTimeout runs, the callback is already queued. The flag is what keeps fireEmitter from doing anything irreversible after the host has decided the instance is dead.

One ordering note in dispose: stopBed goes first so the bed gets its fade-out, and stopAll then hard-stops whatever is still registered, which by that point is just emitters.

That only works because the adapter’s stopBed removes the bed from its live set right away and lets the fade finish on its own, as ours does above. If you write an adapter whose stopAll flattens every sound unconditionally, the fade dies with it, so treat “stopBed unregisters synchronously” as part of the contract.

Wiring it in

The engine is the same in every host; only the lifecycle around it changes.

React. For DOM-hosted Phaser, or plain React UI:

import { useEffect } from "react";
import { Soundscape, type SoundscapeDef } from "./Soundscape";
import { bus } from "./bus";

export function SoundscapeRunner({ sceneId, def }: { sceneId: string; def: SoundscapeDef }) {
  useEffect(() => {
    const scape = new Soundscape(def, bus);
    scape.start();
    return () => scape.dispose();
  }, [sceneId, def]);

  return null;
}

Render it as a sibling to your <Canvas> or Phaser mount. The render tree doesn’t contain audio nodes; the audio engine is a side effect keyed on sceneId.

There’s one footgun: def is an effect dependency, so if you pass an inline object literal, every render disposes the engine and builds a new one. You’ll hear the bed restart and blame the engine, but nothing’s wrong with it. Hoist defs to module scope, like CAFE above, or memoize them.

r3f. It’s exactly the same <SoundscapeRunner>; just put it outside <Canvas>.

<>
  <SoundscapeRunner sceneId={current} def={SCENES[current]} />
  <Canvas>{/* your scene */}</Canvas>
</>

The audio engine has no business inside the render loop, and r3f doesn’t need to know it exists.

Phaser. There’s no React and no useEffect here, so bind to scene events instead.

export function attachSoundscape(scene: Phaser.Scene, def: SoundscapeDef) {
  const scape = new Soundscape(def, bus);
  scene.events.once("create", () => scape.start());
  scene.events.once("shutdown", () => scape.dispose());
  return scape;
}

Call it in your scene’s init(), and that part matters. By the time create() runs, the "create" event has already fired, so that once never resolves and you wait forever for a soundscape that never starts.

If you attach late, call scape.start() directly instead of listening for the event. The shutdown hook does the job that useEffect’s cleanup did in the React case: same shape, different host.

Imperative three.js. Own the instance on whatever your singleton is, and start it after your asset loader’s “ready” event rather than at construction, because the first play has to follow a user gesture or autoplay will mute it.

class World {
  private scape: Soundscape | null = null;

  async load() {
    await this.loader.loadAll();
    // user has clicked "Start" by the time this resolves
    this.scape = new Soundscape(CAFE, bus);
    this.scape.start();
  }

  setSoundscape(def: SoundscapeDef) {
    this.scape?.dispose();
    this.scape = new Soundscape(def, bus);
    this.scape.start();
  }

  destroy() {
    this.scape?.dispose();
    this.scape = null;
  }
}

setSoundscape is the hot-swap: dispose the old one and build the new one. The bus is shared, so the duck state survives the swap, and the live-def demo above does exactly this on every edit.

Across all four hosts, the only thing that changes is who calls dispose.

Single-bus vs multi-bus

Start single-bus, and promote to multi-bus the day a designer asks you to lower the music but keep the SFX at full. Both satisfy the same BusAdapter contract, so the engine doesn’t change. Here’s the same def on the same engine, with only the adapter underneath swapped:

An interactive demo goes here. Open the post to try it.

Howls and the loading bar

This one tripped me up. In three.js you already have a LoadingManager driving the loading UI, but Howl downloads happen outside it by default, so the bar finishes before the audio is ready and the first scene loads with the bed still buffering. The fix is to teach Howl to report into the manager:

import { Howl } from "howler";
import type { LoadingManager } from "three";

export function registerAudioWithManager(src: string, manager: LoadingManager) {
  manager.itemStart(src);
  const howl = new Howl({
    src: [src],
    preload: true,
    onload: () => manager.itemEnd(src),
    onloaderror: (_id, err) => {
      console.warn("audio load failed", src, err);
      manager.itemEnd(src);
    },
  });
  return howl;
}

Call this instead of new Howl(...) in your adapter’s preload step and the loading bar waits for audio. Phaser has the same hook through scene.load.start() and a custom file type, and the pattern is identical.

What’s the catch?

The engine assumes you preload every sample by name. Lazy loading is possible, but the contract gets uglier and you owe the user a fallback while a sample streams in.

setTimeout is a lousy scheduler. It’s fine for ambience, because nobody can hear ±50 ms on a creaky-floorboard interval, but it’s no good for musical timing, so don’t repurpose this for that.

The BusAdapter interface is small on purpose. If you want a seventh function, you probably want a different abstraction underneath, not a bigger one on top.

What will bite you?

Every one of these has bitten me in production.

Autoplay. The first sound must follow a user gesture, so gate start() behind a click. On mobile Safari, a programmatic play() before the first interaction fails silently and leaves the Howl half-broken.

StrictMode in dev. useEffect runs twice, so dispose() must be reentrant; the disposed flag above is what makes the second teardown a no-op.

Timer leaks on scene change. Every setTimeout id has to be tracked and cleared, and the check at the top of scheduleNext and fireEmitter is what makes a late timer harmless if one slips past dispose.

Fade, then stop. howl.fade() fires a "fade" event when it finishes. Chain stop() in that callback, as stopBed does, or Howler keeps a zero-volume instance alive forever.

Missing samples shouldn’t throw. Lazy registration, MDX-driven content and hot reload will all ship a name without a sample sooner or later. Log it, return null and keep going.

The engine does not change

I’d start with the single-bus adapter hosted from useEffect, and bring in the mixer the day a designer asks to move the music without touching the SFX.

You’ve heard it on a video call. The other person is talking and the line sounds normal. Then they mute, and their whole room disappears with them: no air conditioning, no chair creak, no car going past the window. The line isn’t quiet. It’s empty.

Most web games mute the room on purpose. They play a footstep, a click and a music loop, and they leave the space between those events silent. The fix is to leave the room on, and I call that layer a soundscape. Flip between the two versions below and you’ll hear the difference straight away.

An interactive demo goes here. Open the post to try it.

What is a soundscape?

It’s the third kind of game audio, and it isn’t music or SFX. If you mix all three on one bus, the game ends up sounding like a YouTube video with the ads left in.

A soundscape has two parts. The bed is a looping ambience: room tone, wind, distant traffic. The emitters are short, non-musical samples that fire on a timer with a little randomness in their pan, volume and pitch. A floorboard creaks, a bird calls once, a door closes somewhere down the hall.

Together they fill the gaps between your SFX, so the room already sounds alive before the player has done anything.

Why is this worse on the web?

None of this is new. Native engines have shipped it for years. Unity gives you AudioMixerGroup, Unreal gives you Submixes and Sound Cues, and you wire up bus routing and priorities in an editor once and then forget about it.

The web gives you an AudioContext (opens in a new tab) and a GainNode (opens in a new tab), and that’s your entire mixer.

The libraries don’t fill the gap either. Phaser ships WebAudioSound (opens in a new tab), three.js ships PositionalAudio (opens in a new tab), and drei wraps that as <PositionalAudio> (opens in a new tab) for r3f. None of them give you scheduled ambience, or a bus that can duck a whole category of sounds while a voice-over plays.

So most web games never get past music plus SFX. The work isn’t hard. Nothing in the tooling nudges you toward it, so it quietly never happens.

Isn’t ambience just a quiet music loop?

I used to think so. Drop a 30-second room-tone MP3 into the music slot, set the volume to 0.2, and call it ambience.

The trouble is that the ear clocks a static loop fast. Within about three repeats your brain has found the seam, and once it has, it can’t stop hearing it. A single unchanging loop ends up with the mood of a fridge hum: the room is on, but nobody’s home.

But isn’t a quiet loop better than nothing?

Yes, it is. A bed on its own beats silence. It’s the baseline, and emitters are what you put on top of it.

Here’s what thirty seconds of the café demo actually does. The bed runs the whole time. Every few seconds an emitter picks a sample, a volume and a pan, and fires once.

A short crossfade at the loop point hides the restart, and the emitters give the ear something more interesting to follow than the seam. The demo below has both. The red flash marks the exact moment the loop wraps, so try to hear it with the emitters off and then on.

An interactive demo goes here. Open the post to try it.

Stand still in a real room for a minute and just listen. What you hear isn’t one texture. A fridge compressor kicks in, a neighbour’s door closes, the floor settles, a gust hits the window. None of those are looping. They’re events on top of a near-silent bed, and a soundscape system is exactly that, on a timer.

The knobs

There are three, and skipping any one of them turns the layer back into a tape loop.

A sample pool per emitter, with last-picked exclusion. Each emitter holds three to six short samples. Every fire picks one at random, but never the one it just played. The ear catches an immediate repeat faster than anything else, which makes this the biggest win for the least work.

Random pan, volume and pitch, within tight ranges. Pan ±0.4, volume 0.7 to 1.0, playback rate 0.95 to 1.05. That’s tight enough that nothing sounds broken and wide enough that no two fires are identical. Pitch is the easy one to overdo: past about ±5%, samples start sounding chipmunky or sluggish. Ask me how I know.

A concurrency cap. maxConcurrentEmitterInstances stops pile-ups. Every so often the dice will fire three emitters within 200ms, and without a cap that moment craters the mix and clips the master. Cap it at three or four. It’ll kick in maybe once a minute, and you won’t hear it when it does.

Everything else is plumbing. Play with all three in the playground below.

An interactive demo goes here. Open the post to try it.

Same engine, different emphasis

The same three knobs show up whatever you’re building. What changes is which one you lean on.

2D Phaser games. Tie the bed to the scene and schedule emitters from the scene’s update loop or from timers. The listener rarely moves, so pan is decoration more than space. Three or four samples per emitter with last-picked exclusion is plenty.

3D three.js or r3f games. The bed stays 2D, because room tone doesn’t come from anywhere; it’s everywhere. Emitters can stay 2D and randomized, or become real positional sources with PositionalAudio (opens in a new tab) when they should pan as the camera turns. Ducking matters more here, because dialog gets buried quickly when music, footsteps and UI are all competing for the same space.

Narrative scenes. This is where ducking pays off most. Without it, the voice-over fights the ambience and you end up cranking the VO bus until the room is a whisper. Instead, duck the ambience bus over about 120ms when a line starts and release it over about 450ms when the line ends. The voice sits on top, and the room comes back when it’s done.

An interactive demo goes here. Open the post to try it.

What’s the catch?

It’s more authoring. Three to six samples per emitter is real work compared to one, and you’ll feel that budget the first time a designer asks for “one more bird.”

The concurrency cap means an emitter you wanted to hear will occasionally get dropped. That’s almost always fine, but once in a while the dropped fire was the one sound that sold the room.

Ducking adds buses, and bugs like to hide in bus routing. If you have one bus today, you’ll have four tomorrow.

And the whole layer is invisible when it works. Nobody on the team will notice it, which is the point, but it makes for a tough sprint review when your demo is “the room, except now it sounds like a room.”

What should you not do?

I’ve done every one of these at least once.

Start the bed at full volume with no fade-in. On first load the player hears a hard cut into ambience. A 500ms fade-in costs nothing and removes it.

Use hardcoded <audio> tags. They give you no bus routing, no ducking and no per-instance volume, and you can’t duck what you can’t address. Use Web Audio, or a wrapper like Howler, for anything that has to share the stage with other sounds.

Create a new Howl for every emitter fire. That leaks memory and re-decodes the sample each time. Construct each Howl once at load, then call play() per fire.

Duck by pausing the bed. Pausing loses the loop’s position and you get a click on resume. Lower the bus gain instead.

Forget to clear timers on scene change. A setTimeout armed in scene A will happily fire an emitter in scene B. Track every timer id, clear them all on dispose, set a disposed flag, and check that flag before re-arming inside the recursion.

If you only take one of these home, take the timers one. It’s the one that finds you at 11pm.

Part 2

Part 2 builds this for real: one engine-agnostic class, a six-function bus adapter, and bindings for React, Phaser and plain three.js. The engine itself is under a hundred lines. What changes from game to game is the bus underneath it and the lifecycle wiring above it.

If you only have an afternoon, start with last-picked exclusion and a concurrency cap. Those two knobs are what stop a bed from sounding like a tape.