Lyra and Satin: AI-Native Codecs for WebRTC Voice in 2026

Google announced Lyra V2 in 2022. Microsoft announced Satin the same year. Three years later neither has shipped in WebRTC. Opus 1.5 with deep-PLC won the production race in 2026.

The Lyra/Satin promise

Both Lyra (Google) and Satin (Microsoft) used neural decoders to reconstruct intelligible speech at bitrates Opus could not touch:

• Lyra V2: 3.2 kbps roughly equivalent to Opus at 10 kbps; 6 kbps roughly equivalent to Opus at 13 kbps.
• Satin: super-wideband at 6 kbps, full-band stereo at 17 kbps, robust under heavy packet loss.

The pitch was simple: the same call quality at one-third the bitrate, plus better robustness to loss. For AI voice in low-bandwidth markets that should be a slam-dunk.

What actually happened

Neither codec made it into the WebRTC mandatory-to-implement list. Reasons:

• Patent and licensing uncertainty on the neural model side.
• The complexity of running an inference pass in the codec path on every device, including Android entry-level.
• Opus 1.5 (March 2024) shipped a neural deep PLC (`opus_decoder_dpll`) and learned-tuning improvements that closed most of the quality gap on packet loss.
• AI voice teams started running noise suppression and dereverb out-of-band (RNNoise, krisp, NVIDIA Maxine), which is where the perceived quality wins actually came from.

By 2026 the production stack is overwhelmingly Opus 1.5 with deep-PLC, plus a Web Audio or Worker-side denoiser. Lyra and Satin are interesting research; not WebRTC features you can flip on. Microsoft uses Satin inside Teams for non-WebRTC paths but does not expose it to third parties; Lyra remains an Android-only library outside browsers.

The 2026 reframing: AI codec wins for AI voice are not in transmission; they are in pre-processing (denoise, dereverb, AGC) and post-processing (PLC, BWE). Opus stayed because it is the right size for the actual problem on the wire.

CallSphere stack

CallSphere ships Opus 1.5 across all six verticals (real estate, healthcare, behavioral health, legal, salon, insurance). The /demo path uses our Encoded Transform worker for noise suppression, and SDP munging pins `useinbandfec=1; usedtx=1; maxaveragebitrate=24000`. That gets us:

• 24 kbps mono full-band, ~3.7 MOS on clean networks.
• Deep-PLC keeps audio intelligible to ~8% packet loss.
• Worker-side denoising adds ~3–4 ms per 10 ms frame.

Explore a live demo and compare current plans to find the right fit for your business.

Architecture

```mermaid flowchart LR Mic --> Worker[Worker - RNNoise] Worker --> Encoder[Opus 1.5 encoder] Encoder -- 24 kbps --> Net Net --> Decoder[Opus 1.5 decoder + deep-PLC] Decoder --> Speaker ```

Code snippet (browser SDP profile)

```ts function tuneOpus(sdp: string): string { return sdp.replace(/a=fmtp:111.*/g, [ "a=fmtp:111 minptime=10", "useinbandfec=1", "usedtx=1", "stereo=0", "maxaveragebitrate=24000", "maxplaybackrate=48000", ].join(";")); }

const offer = await pc.createOffer(); offer.sdp = tuneOpus(offer.sdp!); await pc.setLocalDescription(offer); ```

Build steps

1. Pin Opus 1.5 features in the SDP via munging (FEC, DTX, max bitrate) — see the SDP munging post.
2. Run noise suppression in a Worker on the browser side; do not rely on the codec.
3. Track `media-playout.concealedSamples` to validate deep-PLC is doing its job.
4. Keep Lyra/Satin in your "watch list" but do not bet schedule on them.
5. Re-evaluate at the next IETF meeting; if either codec gains a clear license path, reconsider.
6. Test bandwidth scenarios (24 kbps, 48 kbps) in your CI; codecs misbehave at edges.
7. Audit your SBC bridges — many still hand-back PCMU only; do not let that pull your call quality down.

Common pitfalls

• Not enabling FEC — default Chromium config does not enable in-band FEC. You will lose 5–10% of frames audibly on cellular.
• Stereo on voice — wastes bitrate on mono content. `stereo=0` is cheap insurance.
• Skipping DTX — silent intervals send packets. `usedtx=1` cuts ~30% on conversational paths.
• Misconfiguring max bitrate — too low and music sounds bad; too high and you waste TURN egress. 24 kbps is the sweet spot for English speech.
• Choosing PCMU for SIP-to-WebRTC — if you control both ends, transcode to Opus.

FAQ

Is Lyra in any browser? Not in WebRTC. Available as a standalone library in Android voice apps.

Does Satin ship in Teams? Microsoft uses it inside Teams for non-WebRTC paths; not exposed to third parties.

Why didn't Opus die? Opus 1.5 closed the gap with deep-PLC. Patent freedom and ubiquity beat marginal codec wins.

Will AI codecs ever land in WebRTC? Probably — but on a 2027–2029 timeline, not now.

What about new codecs from Meta or Apple? Both have research; neither has a shipped browser codec.

Should I plan for codec migration? Plan the SDP munging code so a swap is trivial; do not actually swap until a new codec is mandatory.

Does deep-PLC consume more CPU? Marginally — Opus 1.5 deep-PLC adds 0.2 ms per frame on M2; not measurable on Snapdragon.

Is there a bandwidth-quality dial I can expose to users? Not directly — set bitrate via SDP munging; the user-facing dial is "Auto/Better/Best."

Production playbook for AI voice teams in 2026

Three rules from running Opus 1.5 across all six verticals:

1. Tune for speech, not music. `stereo=0; maxaveragebitrate=24000` is the right profile. Music is a different product.
2. Pin the version in the build manifest. A silent libopus upgrade can change PLC behaviour subtly. Lock it.
3. Compare against the noise-suppression layer. The biggest perceived quality wins in 2026 come from the Worker-side denoiser, not the codec. Budget your engineering time accordingly.

The hardest "is it the codec or the denoiser?" question we ever answered: an A/B with codec frozen, denoiser swapped, vs codec swapped, denoiser frozen. Denoiser changes accounted for 92% of the perceived quality delta. That is where to invest.

Watch list 2026

• Opus 1.6 is in pre-release and may add neural BWE plus more PLC tuning. Worth following.
• Apple's CoreAudio AI codec (rumored) might land in iOS 19; would change the calculus on Safari.
• Lyra V3 (no public timeline) — Google has not abandoned the project but has not scheduled it either.
• Codec-agnostic noise suppression — RNNoise V2 and Maxine continue improving; codec choice matters less every year.

Sources

• https://opensource.googleblog.com/2022/09/lyra-v2-a-better-faster-and-more-versatile-speech-codec.html
• https://bloggeek.me/lyra-satin-webrtc-voice-codecs/
• https://opus-codec.org/release/stable/2024/03/04/libopus-1_5.html
• https://en.wikipedia.org/wiki/Lyra_(codec)
• https://rtcwebdev.medium.com/new-ai-based-audio-codecs-in-webrtc-lyra-satin-d32987ab789f
• https://research.google/blog/lyra-a-new-very-low-bitrate-codec-for-speech-compression/?m=1

Explore a live demo and compare current plans to find the right fit for your business.