- From: <bugzilla@jessica.w3.org>
- Date: Tue, 19 Jun 2012 14:43:59 +0000
- To: public-audio@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 UTC