Proposal: livekit-plugins-rnnoise - OSS NC plugin for self-hosted deployments

[thestubbornbat]

Feature Type

Nice to have

Feature Description

Issue:

Self-hosted LiveKit Agents deployments currently have one open-source NC option: aloware/livekit-plugins-dtln (third-party). The upstream livekit-plugins-noise-cancellation ships Krisp BVC, which requires LiveKit Cloud — and per the noise-cancellation-docs, "Krisp BVC usage will incur an additional cost beginning May 1, 2026."

Proposal:

Publish livekit-plugins-rnnoise, wrapping Xiph.Org's RNNoise (BSD-3-Clause) as an rtc.FrameProcessor[rtc.AudioFrame]. Not as a replacement for DTLN, but a complementary point on the quality/latency/footprint curve, analogous to how the STT/LLM/TTS plugin lineups offer multiple providers.

I'd ship it standalone first. Filing this to check for demand/interest and other upstream concerns.

---

Proposed scope (v0.1)

• RNNoiseFrameProcessor — FrameProcessor[AudioFrame] conformant, 48 KHz / 10 ms / mono
• librnnoise vendored inside each wheel — no system dependency
• Prebuilt wheels via cibuildwheel: Linux x86_64 + aarch64, macOS arm64 + x86_64, Windows amd64. librnnoise vendored — no system dep
• Unit tests
• README with quality comparison vs. DTLN and Krisp BVC

Questions for maintainers

1. Monorepo path — if v0.1 ships standalone and picks up traction, would you consider upstreaming under livekit/agents? Or should OSS NC plugins stay third-party indefinitely, as DTLN has?
2. Docs visibility — is there a page (self-hosting guide, plugin directory) where OSS NC options would be listed alongside Krisp, so self-hosters can discover them?

Offer

Happy to build and maintain this as an independent contributor. Not looking for default status — just a supported, discoverable alternative for self-hosters. Directional feedback appreciated before I start.

Workarounds / Alternatives

• Krisp BVC via livekit-plugins-noise-cancellation — requires LiveKit Cloud; not viable for self-hosters. Moves to paid in May 2026.
• aloware/livekit-plugins-dtln — existing third-party, works well, but covers a different point on the curve (see comparison below). A single option isn't enough for a plugin category that the STT/LLM/TTS plugin lineups approach with multiple providers.
• Rolling a custom FrameProcessor per-deployment — what some teams do today; no shared maintenance, no shared benchmarks.
• See #3073 — asked about using custom NC on self-host, closed without public guidance.

Additional Context

Why both DTLN and RNNoise

	RNNoise	DTLN (existing plugin)
Frame / lookahead	10 ms frame (480 samples @ 48 kHz)	32 ms block, 8 ms shift
Model weights	~88 KB (88k 8-bit weights)	~4 MB ONNX
Runtime dep	Tiny native lib (librnnoise)	ONNX Runtime CPU wheel (~15–20 MB)
Native rate	48 kHz full-band	16 kHz
Quality	Solid on stationary + non-stationary noise	Higher ceiling (PESQ 3.04 / STOI 94.76% on DNS-Challenge)
Track record	Ships with OBS Studio (since v26, 2020); 2018 Xiph paper	Newer, narrower deployment

DTLN wins on measured quality. RNNoise wins on install footprint and full-band support. Even though steady-state compute is low for both, it'd be good to have options.

[akashicMarga]

@thestubbornbat it would be great to add this i pipeline as an option, did you start on this?

[thestubbornbat]

No, I haven't. I was waiting for some feedback before starting anything.

[lleitner]

@thestubbornbat I'm highly interested in such a feature. Unfortunately not an expert in NC, so sorry if thats a dumb question: but what speaks against implementing such a feature with DeepFilterNet 3?