The problem is that this lets you generate a buffer, and when you're done with that, play it back, but it doesn't let you push blocks of audio continually while previous blocks play. That will be necessary for any real-time audio application like NES emulation. Ultimately, this should be solved with the Web Audio API, but so far that appears to implemented in Firefox/Chrome/Safari, and only partly in those. I can see a Flash shim being useful there.

Now, in the mean time, I do have an idea of how this might be implemented on top of Riffwave.js, but it's iffy. The problem is that while the HTML5 audio element does have some events that tell you about playback status, we cannot possibly rely on JS events (or the placement of new audio tags) to give us the temporal granularity needed for audio timing. If you mistime the beginning of one block from the end of the previous block by half a millisecond, you'll hear an audible pop.

So one possible solution would be to crossfade blocks, using an overlap period on the same order as your timing uncertainty. In the cleverest implementation, the timing uncertainty would be continually measured and the overlap size would be adapted to be as low as possible.

But that's not a perfect solution. It would ameliorate the problem, but it would also introduce its own artifacts. For example, if you have a 440 Hz sine wave playing, and one block is offset by the next by 1.13 ms, then at the midpoint between two blocks (where each block is at 50% volume), the waves will interfere completely, resulting in a point of silence. The artifact would be soft, but it would still be a problem.