Re: [web-audio-api] (JSWorkers): ScriptProcessorNode processing in workers (#113)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#23) by Jussi Kalliokoski on W3C Bugzilla. Tue, 19 Jun 2012 14:43:58 GMT

(In reply to [comment #22](#issuecomment-24244428))
> (In reply to [comment #20](#issuecomment-24244414))
> > Developers have to be conscious about performance and avoiding layout reflows
> > anyway, why should this API be any different?
> 
> I'd also like to add to this discussion that you can't really compare glitches
> in graphics/animation to glitches in audio. In general we (humans) are much
> more sensitive to glitches in audio than to frame drops in animation. You can
> usually get away with a 100 ms loss in an animation every now and then, but you
> can't as easily get away with a 1 ms glitch in your audio.
> 
> Most systems (DVD, DVB etc) prioritize audio over video. This can be seen when
> switching channels on some TV boxes for instance, where video stutters into
> sync with the continuous audio - it's hardly noticeable, but it would be
> horrible if it was the other way around (stuttering audio).
> 
> In other words, an audio API should provide continuous operation even under
> conditions when a graphics API fail to do so.

Yes, this is why it is preferable to run audio in a real time / priority thread where possible, but it's not always possible, maybe due to the system or the nature of the application.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-24244441