Skip to content
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

Closed
wants to merge 11 commits into from

Conversation

orottier
Copy link
Owner

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.

@orottier
Copy link
Owner Author

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.

@b-ma
Copy link
Collaborator

b-ma commented Apr 29, 2024

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?

@orottier
Copy link
Owner Author

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!

@orottier orottier closed this May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants