Use a larger buffer size for recording to prevent glitching

[paulkaplan]

Resolves

What Github issue does this resolve (please include link)?

Helps with #1735

Proposed Changes

Describe what this Pull Request does

Use an 8x larger buffer size for script processor node, which allows the browser much more leeway in terms of how quickly it needs to run the script processor node before buffers start getting dropped. This does not impact the smoothness of the visualization, which is run at RAF framerate using a separate analyzer path.

I had to change the stop function, which previously was relying on the buffer size being 1024 implicitly (it would submit RMS chunks depending on the script processor buffer length). Instead use the other RMS utility by switching around the order of operations.

Reason for Changes

Explain why these changes should be made

By using a small buffer size, we were causing glitchiness in exchange for latency, which it turns out we do not need because we are recording!

[rschamp]

Try it out: recording-glitch

I'm a bot, not actually @rschamp!

[ericrosenbaum]

LGTM! I tested a bit on mac chrome, firefox and safari. This doesn't totally prevent glitchy recordings of course (e.g. when using cpu throttling, or using video sensing with lots of clones etc), but it does seem to reduce the problem. when the glitching is severe, this make it sound less bad because the glitches are spread apart more.