You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: