Release packages

[knope-bot]

Important

Merging this pull request will create these releases

livekit-api 0.4.15 (2026-03-13)

Fixes

Bump jsonwebtoken to v10 to address CVE-2026-25537

#917 by @gasmith

livekit 0.7.33 (2026-03-13)

Fixes

enhanced build configuration to support macOS and iOS platforms with proper system library linking

#847 by @SchmErik

fix video track subscription in single peer connection mode

#914 by @xianshijing-lk

livekit-ffi 0.12.49 (2026-03-13)

Fixes

• Update livekit dependencies

livekit-wakeword 0.1.1 (2026-03-13)

Features

Add livekit-wakeword crate with ONNX-based wake word detection

#926 by @pham-tuan-binh

Summary

• New livekit-wakeword crate with a stateless wake word detection pipeline
• Pipeline: raw PCM audio → mel spectrogram → speech embeddings → classifier scores
• Mel spectrogram and embedding models are bundled at compile time via include_bytes!
• Wake word classifier models (e.g. hey_livekit.onnx) are loaded dynamically from disk at runtime
• Supports multiple classifiers simultaneously, each returning a confidence score (0-1)
• Input sample rate resampling via FIR resampler (supports 16–384 kHz, internally resamples to 16 kHz)
• Pure-Rust ONNX backend via ort-tract (falls back to native ONNX Runtime on aarch64-pc-windows-msvc)
• Fix mel spectrogram post-processing normalization (x/10 + 2) to match the openWakeWord pipeline
• Custom WakeWordError enum replacing Box<dyn Error> in the public API

Test plan

• cargo test -p livekit-wakeword — integration tests exercise the full pipeline
• Validates score output is in [0.0, 1.0] range
• Validates too-short audio returns zero scores
• Positive WAV sample ("Hey LiveKit") scores >= 0.5 threshold
• Negative WAV sample (non-wake-word audio) scores < 0.5 threshold
• Rust scores match Python reference implementation (0.9997 positive, 0.0009 negative)

webrtc-sys 0.3.24 (2026-03-13)

Fixes

avoid getting webrtc into underrun

Before this change, the Rust implementation would only start sending silence frames after missing 10 consecutive audio frames. This could cause WebRTC's audio pipeline to enter an underrun state when audio stopped temporarily.

Once WebRTC enters underrun, resuming audio can significantly increase latency until the pipeline stabilizes again. In testing, this could add hundreds of milliseconds of additional latency when audio resumed shortly after the underrun.

This change ensures silence frames are sent earlier to prevent the audio pipeline from entering underrun. By maintaining a continuous stream of audio (including silence), WebRTC can avoid unnecessary buffering and latency spikes when audio resumes.

In testing, this reduces the additional latency observed after underrun recovery and results in more stable end-to-end audio latency.

webrtc-sys: Handle gracefully lack of libva on linux

#924 by @kubkon