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

Re: Web Audio Trashing Bugs Inside Google Chrome

From: Grant Galitz <grantgalitz@gmail.com>
Date: Sat, 10 Sep 2011 15:15:22 -0400
Message-ID: <CAD8zUBbgENp14t2yRt_E2h9A2ND3oThCLtLmYt-GUkTKazUh2A@mail.gmail.com>
To: public-audio@w3.org
I'm just wondering, I hear gaps at regular intervals on mac os x actually
(Not GC instances, and CPU load is pretty stable, and happens once every
minute or so like a sample isn't being accounted for due to a floating point
underrun). Is web audio even peeking at the audio buffering, or is it just
running blind with some counter (Which causes this kind of issue in a lot of
apps)?

> Hi Grant,
>
> We're actively working on platform-specific audio back-end performance
> tuning for the Web Audio API in Chrome.  We have a new engineer specifically
> working in this area.  I'm sorry you're having problems with your
> application right now...
>
> Chris
>
> On Wed, Sep 7, 2011 at 6:19 PM, Grant Galitz <grantgalitz@gmail.com <grantgalitz@gmail.com?Subject=Re%3A%20Web%20Audio%20Trashing%20Bugs%20Inside%20Google%20Chrome&In-Reply-To=%253CCA%2BEzO0n316v8OtHFFjBtLf2SwVy47YjGswkPMO1BOtSeRojL5g%40mail.gmail.com%253E&References=%253CCA%2BEzO0n316v8OtHFFjBtLf2SwVy47YjGswkPMO1BOtSeRojL5g%40mail.gmail.com%253E>> wrote:
>
> > I'm not sure how many people are aware, but using the onprocessaudio event
> > with a javascript audio node has trashing issues inside Google Chrome on
> > Windows and Linux (But not Mac OS X!). Even when nothing is blocking the
> > onprocessaudio callback, the API experiences audio underruns, causing
> > complete trashing of the resulting audio output. I've gone ahead and blocked
> > the Web Audio API for Windows and Linux users using my XAudioJS library (
> > https://github.com/grantgalitz/XAudioJS ). These people now are using the
> > Flash fallback, which uses the same core functions as the Web Audio API path
> > in my library, yet does not have nearly as much as a problem with audio
> > glitching as Web Audio, not to mention there is a higher load from the
> > javascript->flash bridge, as flash calls js to request refills. To block out
> > chrome users by Operating System is a nasty thing no one wants to do, but
> > it's basically come down to this since Web Audio has been enabled by default
> > in chrome now (Not in about:flags anymore in canary at least) and that this
> > bug has been present since it pretty much first landed.
> >
>
>
Received on Saturday, 10 September 2011 19:15:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:56 UTC