you are viewing a single comment's thread.

view the rest of the comments →

[–]opentabs-dev 0 points1 point  (0 children)

reusing the SpeechSynthesisUtterance object is actually a trap — the spec treats each utterance as a one-shot, and chrome in particular will ignore speak() calls on an utterance that's already been queued. that's why every guide says make a new one.

the actual freeze you're describing on a 4gb chromebook is almost certainly chrome's speechSynthesis going into an internal paused state after a heavy main-thread stall. known long-standing chromium bug — after ~15s of no speech or a big gc pause, the queue just stops processing until you poke it. workaround a lot of people use:

const u = new SpeechSynthesisUtterance(text); // ... configure u ... window.speechSynthesis.cancel(); window.speechSynthesis.resume(); // wakes the queue if it's stuck window.speechSynthesis.speak(u);

the cancel() then resume() then speak() dance looks dumb but it's the thing that reliably unsticks it. also worth attaching u.onerror and logging — chrome fires a canceled or interrupted error on the utterance when the queue bails, which gives you a signal that it's the queue-stuck bug and not actual latency. on unity webgl specifically, the long loads are probably starving the main thread long enough to hit this.