Otto Rottier

Very nice, the previous implementation could definitely use some more concise and well-organized methods. I need some more time for the reviews, hopefully tomorrow!

Some initial work at https://github.com/orottier/web-audio-api-rs/commit/92ba3f03d741a95ce2013929c8d3f7548cda1fbc - showing it might not always be worthwhile

> Yup, maybe a bit convoluted if the improvement is small. We should rewrite the biquad, iir, stream_destination and many other nodes to use this optimization and see if they...

Hey, the idea is nice, but it will break the channel-splitter and merger. And I'm not sure if I like the magic around it. What if a AudioWorkletNode specifies an...

Removing the v1 milestone because this is not part of the public API. The `Microphone` struct however is, and could benefit from the same config settings we'd like to pass...

Some work was done but we still need to implement the desired `buffer_size` AKA latency hint

Yeah, it's a good point to decide now how to continue. The current implementation is a terribly inefficient, mostly correct, version of the overlap-save method of performing convolution in FFT...

Or port the C++ code to Rust. It is about 5k lines of code..

> can we make ConcreteBaseAudioContext pub(crate) only? I like the idea, but there is no simple solution, because in rust a function must return a concrete type. It is not...

Let's start simple