- From: John Byrd <jbyrd@giganticsoftware.com>
- Date: Tue, 11 Jun 2013 11:12:36 -0700
- To: Russell McClellan <russell@motu.com>
- Cc: lonce <lonce.wyse@zwhome.org>, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAM5hBBtrdZz7tR=d7QrKwVBJv3AnBWmeZraxme_Gb5YygTruKQ@mail.gmail.com>
> Right, I suppose there are two issues here - _preventing_ glitches, and > _detecting_ glitches. I was only asking about detecting them. As John > Byrd noted, as far as I know there isn't an accepted best practice in how > to prevent them, but detecting them seems like a very solvable problem. An > event on the ScriptProcessorNode seems reasonable to me. > > Across the set of all possible DSP, preventing glitches is actually impossible -- it's a special case of the halting problem. Assume that you have a perfect algorithm A that consistently detects whether a glitch will occur on a certain frame F. In that case you could write a DSP plugin that is guaranteed to glitch: if ( not A(F) ) consume_tons_of_cpu_time_uselessly(); However, in the practical case, there are several things to note when designing a node-based API to avoid glitching. First, note that glitches tend to mostly occur in situations where CPU load is inconsistent from frame to frame. Audio codecs, not effects, are the major offenders in this regard. Ogg Vorbis codecs are particularly naughty in this regard as they tend to hog a lot of CPU on the first frame while setting up their codebooks. MP3s are somewhat less naughty but still naughty. Codecs and other processes that do not manifest consistent CPU load can be asked to delay processing a few frames until CPU loosens up a little. Second, while a glitch is bad and should never occur, in practice users will forgive a single, extremely rare glitch if the API takes immediate action to root out the offending DSP unit and remove it from play. This however requires that the API would have to, at the node level, be able to provide reporting details about DSP time utilized on every frame. Third, rendering nodes in priority order up to a fixed deadline reduces some (not all) dropouts in some cases. I wonder to what extent Chris or others have contemplated these issues. I suspect that some Web Audio stress tests may exist but I haven't found them. If they don't exist, that would likely be an omission in the current webkit/blink implementation. On an unrelated note: I'm at E3 all week. If any other hardcore audio geeks wanna hook up for a beer, shoot me a direct e-mail please. I'm much nicer in person :) -- --- John Byrd Gigantic Software 2102 Business Center Drive Suite 210-D Irvine, CA 92612-1001 http://www.giganticsoftware.com T: (949) 892-3526 F: (206) 309-0850
Received on Tuesday, 11 June 2013 18:13:23 UTC