emscripten
emscripten copied to clipboard
Block size specification for audio worklet
Audio worklet right now has an unchangable block size of 128, which lowers the latency, but it can come in too fast, or unfit for the provided processing algorithm.
This can also be a waste of performance in case of a multi-threaded audio processor. For example, if one generates audio blocks of 2048 samples, the audio callback is called at a higher frequency than processing. I'm pretty sure this implies more cache misses and more context switches in the long run. Would it be a difficult feature to add ?
I think it can be easy if block size allowed is a multiple of 128, since we can just allocate it once, accumulate with calculated offset while keeping track of count, and run the callback function on the buffer. Then we can keep reusing it since this is shared memory
@juj any feedback on this? IIRC this has maybe come up before?