Re: Info on WebAudioAPI demos and glitches / stutter.

On Tue, Nov 15, 2011 at 1:57 PM, Jane's Conference <
janesconference@gmail.com> wrote:

> Hi public-audio list, hi Chris,
>
> I don't know if it's the right place to write, but I found these addresses
> on the Web Audio Examples page (
> http://chromium.googlecode.com/svn/trunk/samples/audio/index.html) for
> any feedback about the demos.
>
> I'm currently debugging my HTML5 synth demo, which by the way I hope I can
> submit to you to be included in the examples page when it's finished (you
> can find a 0.1beta version here:
> http://dl.dropbox.com/u/6767816/develop/MorningStar_0.1_beta/index.html along
> with the source code here: https://github.com/janesconference/MorningStar
> ).
>
> The demo fully supports Web Audio API and, to a certain extent, Firefox's
> mozAudio. When I run it on Chrome browsers (15.0.874.120 at the time of
> writing), I experience stutters and glitches on the sound. Raising the
> bufferSize of my JavaScriptAudioNode doesn't help at all.
>
> I tought it was my fault, but exploring the demo programs in the Web Audio
> Examples pages led me to discover that every demo in the page (from the
> most cpu-intensive, say the DrumMachine, to the least ones) behaves in the
> same way: stuttering and glitching, on the three PCs I can lay my hands on
> (an old Ubuntu Centrino notebook, a Vista Core2 Duo PC and an Ubuntu
> quad-core workstation I use at my workplace). Opening the examples in an
> incognito window, to exclude Chrome extensions, doesn't help.
>

Hi Cristiano, I'm sorry for the problems you've been experiencing.  On the
machines we regularly check with the Web Audio examples and other tests,
it's not our experience to see these issues.  It's probably best if we take
each case separately (specific hardware and OS) to try to see what's going
on and try to fix the problems.

In Chrome, as you might expect, we have completely different audio back-end
code for Mac OS X, Windows, and Linux.  Here's the status of each:

1.  Mac OS X: generally very well tested with great latency
2. Windows: currently we use an older API (wavOut API) which does not have
as good latency performance as the Mac OS X implementation, but still
generally works ok.  We're just about to upgrade this path to use the
WASAPI API where we're seeing substantially better performance and I'm
really excited about how much of an improvement this gives us.  But this
new codepath is very new and is not yet shipping.
3. Linux: this is the most tweaky of all.  Because there are so many Linux
distributions which run on such a range of hardware with different drivers,
etc. it's more difficult to get consistent results.  Some people use Pulse
audio, some don't, etc.  Some have custom .asoundrc files configured in all
kinds of crazy ways.  That said, we're investing lots of energy on
improving the Linux audio back-end to get the best possible performance.
 We're *very* interested about this.

For each specific case, if you can, please write up separate "chromium"
bugs (not WebKit) with as much specific details about the exact hardware
configuration, OS, etc. and we can try to help you out.

Best Regards,
Chris




>
> I hypotized that having the Developer Tools windows open would cause - or
> be a con-cause to - the problem, but closing DT's window doesn't help
> either (btw, I don't know the internals: is there a way to deactivate it at
> all? Safari asks if debug should be activated once or forever for a given
> page, Chrome doesn't).
>
> Since this might be an useful feedback on the Web Audio examples /
> demos for you, and an important source of info on what the heck is going on
> for me, I decided to write here and see if someone could help me on this
> issue, or maybe point me to someone who could.
>
> Thanks and best regards, keep up the wonderful work,
>
> Cristiano.
>