W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

[Bug 17415] (JSWorkers): JavaScriptAudioNode processing in workers

From: <bugzilla@jessica.w3.org>
Date: Tue, 19 Jun 2012 14:43:59 +0000
To: public-audio@w3.org
Message-Id: <E1Sgzex-0005u7-EQ@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #24 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-06-19 14:43:58 UTC ---
(In reply to comment #22)
> (In reply to comment #20)
> > 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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 19 June 2012 14:44:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 14:44:02 GMT