Re: Can users determine if audio has glitched?

> 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) )

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

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
T: (949) 892-3526 F: (206) 309-0850

Received on Tuesday, 11 June 2013 18:13:23 UTC