Microphone:getData Memory Behavior

[bjornbytes]

Currently when you get samples from a Microphone using :getData, it always creates a new SoundData object.

Seemingly this is "bad" because it uses more memory and does more allocation work to create and destroy/garbage-collect all of these objects, even in situations where you only need to use the samples temporarily (performing one-time analysis on chunks, stream it to another API/system, etc.).

Can we add an interface that lets you pass in your own Blob or SoundData object that acts as a destination for the microphone samples? That way one object could be reused as the destination over and over again. It would be optional but gives you the ability to manage the memory better if you're willing to do so.

[bjornbytes]

If the Blob/SoundData is too small or incompatible with the microphone's capture settings, I think that would be an error.

[nevyn]

Another alternative design is one of my favorite APIs in iOS, CMSampleBufferPool. Sample buffers are reference counted, and when spawned from a pool, this is overridden so that a count of 0 will return the buffer to the pool. This means the producer of audio sample buffers will create as many in-flight buffers as needed, and the consumer can hold on to them as long or short as they want. by setting a limit on the pool, that also provides a really nice backpressure mechanic.

anyways just my 2c :)

[bjornbytes]

Microphone:getData now takes ([sampleCount], [soundData], [offset]) !