- From: Chris Rogers <crogers@google.com>
- Date: Wed, 7 Sep 2011 18:29:01 -0700
- To: Grant Galitz <grantgalitz@gmail.com>
- Cc: public-audio@w3.org
- Message-ID: <CA+EzO0n316v8OtHFFjBtLf2SwVy47YjGswkPMO1BOtSeRojL5g@mail.gmail.com>
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> 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 Thursday, 8 September 2011 01:29:27 UTC