Fwd: JavaScript GameBoy Color Emulator Using Web Audio

Sent from my iPhone

Begin forwarded message:

*From:* Grant Galitz <grantgalitz@gmail.com>
*Date:* April 10, 2011 4:06:10 PM EDT
*To:* Chris Rogers <crogers@google.com>
*Subject:* *Re: JavaScript GameBoy Color Emulator Using Web Audio*

The thing is, I produce more audio samples when needed. I actually keep
track of how many samples are currently buffered so this sort of thing does
not happen. If you listen in firefox 4 and your web audio build of safari
don't click or pop in-game at all, and it's just chrome acting up. I
basically do logic and protection against buffer underrun for web audio and
moz audio. In web audio, I have to keep my audio buffer JS-side, so
measurement there is easy, while in mozAudio I have to test it out from
mozCurrentSampleOffset and do some counting logic of my own to find the
actual samples remaining.

Sent from my iPhone

On Apr 10, 2011, at 1:55 PM, Chris Rogers <crogers@google.com> wrote:

Hi Grant,

Thanks for the great demos.  It's very cool to see more of them running!

What I suspect is happening with the clicking/popping is that the graphics
performance is somewhat different between the three browsers.  Firefox has
by far the best graphics performance, so the main render thread isn't
getting bogged down as much with the drawing code and has more time to
render audio (in the same thread) without gaps.  Both Safari and Chrome
drawing are worse, but it seems that Chrome's drawing is even more choppy
than Safari, which could explain the differences in audio.

Having graphics and audio rendering run in the same thread, which is the
case here, can lead to these types of audio problems.  Basically, with
audio, if you're not rendering it at a speed which is *at least* as fast as
real-time then there will be clicking/popping/glitches/gaps.  That's pretty
much a law of physics.  Other JS code such as the graphics and other game
engine stuff *must* run fast enough to allow the audio to run at the speed
which it needs.  But that is often difficult to guarantee.

Of course, I think it's also clear that there are clear graphics performance
problems in Chrome/Safari vs. Firefox and those problems should be
addressed.

Chris

On Sat, Apr 9, 2011 at 6:32 PM, Grant Galitz < <grantgalitz@gmail.com>
grantgalitz@gmail.com> wrote:

> Changed the demo page to <http://www.grantgalitz.org/CrazyZone/>
> http://www.grantgalitz.org/CrazyZone/
> Mozilla Audio Data API, WebKit Web Audio, and even WAV PCM Data URIs
> supported.
>
> Web Audio in chrome seems to be buggy and clicking and popping a lot, and
> seems to be related to web audio support in chrome itself. The Safari build
> with web audio works fine with it.
>