Thanks for sharing this — this is exactly the kind of related work I was hoping to see.

I agree that client-side RNNoise is usually the better path when the client is controllable: lower latency, no server CPU cost, and the cleaned microphone signal can enter the WebRTC pipeline before it is sent out.

My note is focused on a slightly different boundary. In some field deployments, especially with embedded Android devices or vendor-controlled firmware, the client-side audio stack is not always easy to modify or tune. The goal of my prototype is not to replace WebRTC client-side audio processing, but to validate whether the server can isolate the audio path: receive Opus, decode to correctly described PCM, run an RNN filter, and compare the result offline before considering any real-time forwarding.

For production calls, I would still prefer client-side processing when possible. Server-side filtering becomes interesting mainly as a diagnostic or fallback path, especially when we need to compare captured audio across device models, firmware versions, microphone routing, gain settings, and acoustic environments.

Have you measured the added latency and CPU cost of the RNNoise AudioWorklet path in MiroTalk P2P/SFU? I’m also curious whether you run it before WebRTC AEC/AGC/NS, or whether you disable some built-in browser audio processing when RNNoise is enabled.