Background
Why another audio lib?
Howler exists. Tone.js exists. Raw Web Audio exists. Here's the gap zvuk fills.
The problem
Game audio on the web has three failure modes:
- Autoplay & iOS Safari. Half the bug reports.
- Polyphony. Spam a slot reel-stop SFX 30 times — the second one cuts off the first
because the same
HTMLAudioElementis being recycled. - Mix discipline. Ducking music under VO. Crossfading menu states. Putting reverb on ambience but not SFX. Web Audio gives you nodes; nobody gives you the routing model.
Where existing libs sit
- Howler — battle-tested, but built around the
HTMLAudioElement/Web Audio split, no first-class mixer model, no parameters, no snapshots. - Tone.js — gorgeous for music synthesis, oversized for game SFX, opinionated around the transport.
- Raw Web Audio — perfect, also a swamp.
What zvuk adds
- An Engine object with an explicit state machine
(
cold → unlocking → live → closed). - A Mixer built declaratively from
createEngineconfig, with named Buses and click-free fades. - A Voice per
play()call — abort signals, lifecycle promises, async iterators of cues. - A codec ladder (
['sfx.webm', 'sfx.m4a']) so you ship Opus to the world and AAC only to old iOS. - An iOS-Safari resume dance that survived production slot games.
What zvuk is not
- Not a synthesis framework. No oscillator graph, no Tone.js Transport. Use Tone for that.
- Not a music-streaming player.
Streamwraps<audio>for long files; it's not a queue. - Not a cross-platform native bridge. v1 is browser-only.
If you are shipping a slot game, an arcade game, a casual mobile-web title, an interactive explainer with sound — anything where you need a real mix, not just "play this clip" — that's the zvuk-shaped hole.