W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

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

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:54 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/113/24244441@github.com>
> [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:
Received on Wednesday, 11 September 2013 14:36:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:24 UTC