-
Notifications
You must be signed in to change notification settings - Fork 16
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
lo and behold: AudioWorkletNode processing via NodeJs #503
Conversation
I have done a small bit of optimizations on the rust side. Currently a process call spends 60% of time in the Node.js runtime, and 40% is spent on overhead due to serialization/deserialization of the values between Rust and Nodejs. Of course, the time in the NodeJs process is also probably half spent on ser/deser. This means we have a lot of room on the table by avoiding deser stuff. We could use a memory mapped file for marshalling the sample values for example. Another thing to do is to implement the message port. That is a bit tricky though and it will probably way easier to implement that using a Worker inside the node-web-audio-api project instead of using a separate node process like in this PR. I will hold off on that for now then. |
Héhé nice, indeed that's full of black magic but it works :) I agree some Worker like implementation is the way to go, but we need to solve how we can control in which thread the worker must live (... but I don't really find information nor similar issues on that point for now...) Maybe we should prepare an issue for the nodejs team to get some feedback and hints at some point? |
I have made a small work in progress with the Worker method. On mobile now so will share some details later. It needs a lot of work still but I'm sure it will be sufficient for most custom audio processing needs. We could even ask users to increase the buffer size if we run into realtime safety issues. If we have that all done indeed it would be interesting to consult some V8 experts! |
Okay so this was pretty cool and at the same time frightening. I guess we should never merge this, but we now have a baseline for JS processing. Performance is not great, and obviously stuff like SharedArrayBuffer from the main JS thread will never work. But those are details.