标签：#webaudio

📝 Originally published (in Japanese) at forge.workstyle.tech . When building voice-based AI interactions in the browser (avatars, voice bots, streaming AI), you’ll inevitably hit pitfalls stemming from audio physics and browser implementation quirks. This article compiles 16 traps I encountered during product development , organized in a symptom → cause → solution lookup format . No need to read from top to bottom—jump straight to the symptom you’re facing. Echo and Self-Response Issues 1. Avatar Responds to Its Own Voice (Despite echoCancellation: true ) Symptom : TTS audio is picked up by the mic, and STT recognizes it as user speech, creating a self-response loop. Cause : AEC (Acoustic Echo Cancellation) requires a reference signal (the "sound to cancel"). Only the browser's official playback paths ( <audio> / WebRTC receiver tracks) serve as references. Custom playback via Web Audio API does not reliably function as a reference . Solution : Return TTS audio from the server as a WebRTC remote track and play it via an <audio> element. This eliminates echoes without text-matching workarounds (tested: 99 seconds of continuous speech with speakers on, zero false user turn detections). 2. Echoes Are Gone, but Speaking Simultaneously with the Avatar Distorts My Voice and Causes Misrecognition Symptom : Only during dual speech, proper nouns get mangled (e.g., "社員数" → "シャインズ"), especially at word beginnings. Cause : Fundamental AEC trade-off. To cancel echoes, AEC suppresses/distorts near-end (user) audio during dual speech. Solution : Mitigate in three layers: ① Increase mic Opus bitrate and enable FEC (see Pitfall 13) ② Provide vocabulary hints to STT (see separate article: use "recent avatar speech" as initial_prompt , not a dictionary) ③ Instruct LLM: "Input is STT transcription with potential errors. Interpret unnatural words as phonetically similar terms and add confirmation prompts." 3. Can’t Suppress Audio from Other Apps (Music, Videos) Symptom : Audio/lyrics fr

Two audio players do not make a fair before-and-after test. If the second player restarts from zero or takes half a second to load, the user is no longer comparing two versions of the same moment. They are comparing two memories. That is a weak way to evaluate any audio effect. It is especially weak for AI processing. A denoiser can remove a fan while softening consonants. A de-reverb model can reduce the room tail while making the voice sound less natural. The output may be cleaner without being better. The preview therefore has one job: let the listener switch quickly enough to hear both the improvement and the damage. The rule I use is deliberately boring. Both versions should contain the same edit and play from the same position. Switching should not restart playback or create a pause. The interface should not hint that one version is supposed to win. Two independent <audio> elements fail surprisingly quickly. Each owns its playback state, buffering behavior, clock, and seek operation. The user ends up finding the same position twice and comparing one sound with a memory of another. A better interface has one transport and one version control: [ Play ] [ Original | Processed ] 00:18 ━━━━━━━ 00:42 The transport decides where playback happens. The segmented control decides which signal is audible. One transport, two signals For a short preview, I decode both files into AudioBuffer s, start them at the same AudioContext time and offset, and route each through its own GainNode . Both sources run; only one gain is open. decodeAudioData() decodes complete file data and resamples it to the context's sample rate. The decoded buffers can then share the same audio clock. See the MDN documentation for format and loading details. The core is small: const context = new AudioContext (); const originalGain = context . createGain (); const processedGain = context . createGain (); originalGain . connect ( context . destination ); processedGain . connect ( context . destination )

🏆 This is a submission for the June Solstice Game Jam 🎯 What I Built Turing's Frequency is a browser-based rhythm game where you decrypt encrypted radio signals by listening to musical patterns and recreating them. Each signal carries a message from a historical figure who changed the world — voices that were silenced, ignored, or forgotten, now restored through your rhythm. 🎮 👉 PLAY THE GAME LIVE 👈 📖 The Story The game is set in 1954 , on the desk of Alan Turing at the University of Manchester. A radio crackles with fragmented transmissions — encrypted messages carrying words of Pride , resistance , and identity . You are a student who has found Turing's last notebook, and with it, the key to decrypting these signals. 🌅 The connection to the June solstice: As you decrypt each signal, the screen literally brightens — from near-darkness to a flood of golden light. The solstice is the moment light and dark trade places, and this game makes that transition tangible. 🎬 Video Demo 👆 Watch the full gameplay loop: title → story → rhythm gameplay → decrypted messages → victory screen with solstice light effect. 🕹️ How to Play Key Action 1 2 3 4 Play notes ↑ ↓ ← → Arrow keys (alternative) Space / Enter Advance screens 🎧 Listen to the signal pattern 🎹 Repeat the notes in order 🔓 Decrypt the message 🌅 Restore the voice 💻 The Code The entire game is a single HTML file (~32KB) with zero external dependencies . No frameworks, no libraries, no asset files — just HTML, CSS, and vanilla JavaScript. mamoor123 / turings-frequency Turing's Frequency - A Rhythm of Light. June Solstice Game Jam 2026 entry. ⚡ Key Technical Decisions 🔊 Web Audio API for all sound: Every tone is synthesized in real-time using oscillators. The game uses a pentatonic scale (C4, E4, G4, C5) so every combination of notes sounds pleasant. No audio files needed. function playTone ( freq , duration = 0.3 , type = ' sine ' , volume = 0.3 ) { const osc = audioCtx . createOscillator (); const gain = audioCtx . create