Open msqr1 opened 5 months ago
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?
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.