-
Notifications
You must be signed in to change notification settings - Fork 890
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alter library to support streaming from a ringbuffer #62
base: master
Are you sure you want to change the base?
Conversation
But wouldn't this prohibits in-place processing? |
All this change does is move the |
In your example, you read from one buffer and output to another. How to transform the following case to fit your changes? buffer_up_to_480(same);
rnnopise_process_frame(state, same, same); // in the old API, one buffer can both be input and output or // in a real-time audio graph, a node has equal input and output size that there will be glitches if not fully filled
if (buffered - input > latency)
rnnoise_process_frame(state, &ring[(input - latency + size(ring)) % size(ring)], &ring[input]); |
It would be great to support the following use cases by simply Case 1: fixed I/O buffers, 128 frames each; intrinsic latency of 640 frames is achieved with a ring buffer of 1920 frames Case 2: variable I/O buffers up to 16384 frames each, input feed and output demand may change but are always equal |
It can still be done exactly the same, what you are asking for can still be achieved with it, the difference is that we can have a ring buffer that wraps around so the data is not linear. Here is your use case using this API:
This change simply allows rnnoise to retain the state when it has been given < 480 samples and was only able to partially process the buffer. Please review the rnnoise source, this does not add any extra buffering or latency. Rnnoise will only process audio in blocks of 480 samples, no more or less. This API change simply allows one to feed it this data in blocks/segments if the source is not providing them at this rate (ie, a resampler may yield odd block sizes) instead of introducing an additional buffer. |
Currently, the following example requires an intermediate buffer between WebAudio and RNNoise: Since your changes introduce an internal buffer. Can it eliminate my intermediate buffer above? Pseudo JavaScript: wasmMemory.set(webAudioInputBuffer); // copy from WebAudio into WASM memory
wasm.pipe(currentBufferLength); // call into C code
// inside WASM: rnnoise_process_frame(state, wasmMemory, wasmMemory, currentBufferLength);
webAudioOutputBuffer.set(wasmMemory.subArray(0, currentWebAudioBufferLength)); // copy back from the same WASM memory Actual JavaScript: https://github.com/wegylexy/rnnoise_wasm/blob/899060eb011b6e95ad70c4dabf475b08e23be2d2/src/processor.js#L18-L21 |
No it does not, read the source! This buffer already exists except it's scoped
and
No idea, you need to figure that out yourself. This is for when you have a buffer that is not a multiple of 480 samples and "WRAPS AROUND", see: https://en.wikipedia.org/wiki/Circular_buffer |
Ah, ok. You move it from the stack to the heap. |
This change allows an application to stream from non contiguous memory avoiding the need for an intermediate buffer. For example: