Add Linux/Windows support for audio renderer (audio frame capture)

[alfredobs97]

Summary

AudioFrameCapture.start() currently fails on desktop Linux and Windows with:

MissingPluginException(No implementation found for method startAudioRenderer on channel livekit_client)

The Dart layer already routes desktop platforms to the native implementation (audio_frame_capture_native.dart), but native handlers for startAudioRenderer / stopAudioRenderer exist only on iOS, macOS, and Android. The Linux and Windows plugins handle only startVisualizer / stopVisualizer and fall through to NotImplemented().

This PR adds the missing handlers, bringing Linux and Windows to parity with iOS/macOS/Android for AudioFrameCapture.

Implementation

The low-level AudioTrackSink infrastructure was already in use by the audio visualizer on both platforms, so the change is additive and self-contained — no changes to flutter_webrtc or the Dart layer are needed.

• shared_cpp/audio_renderer.{h,cpp} (new): platform-agnostic conversion pipeline, a direct port of the Android AudioRenderer / AudioResampler:
  • validate (WebRTC sinks always deliver int16 PCM; anything else is dropped)
  • resample: passthrough / linear interpolation (upsample) / box filter (downsample, anti-aliasing)
  • channel reduction: keep the first N channels (matching Android)
  • encode as little-endian int16 or float32 bytes
• linux/livekit_plugin.cpp, windows/livekit_plugin.cpp: new AudioRendererSink class, structurally cloned from the existing VisualizerSink (EventChannel + StreamHandlerFunctions, AddSink/RemoveSink, task-runner hop to the platform thread). Streams converted frames to Dart over io.livekit.audio.renderer/channel-<rendererId>. Unlike the visualizer, frames arriving before a subscriber attaches are dropped rather than queued, matching the Android renderer semantics for live audio.
• Method handlers mirror the Android handleStartAudioRenderer / handleStopAudioRenderer contract: same argument validation and error codes (INVALID_ARGUMENT, No such track), idempotent start for an existing rendererId, and success on stop for unknown ids.
• CMakeLists: shared_cpp/audio_renderer.cpp added to both platforms' sources.

Testing

• The shared conversion pipeline was exercised standalone (passthrough, upsample, downsample, float32 encoding, channel reduction, invalid-input drops, format defaults).
• The event payload matches what audio_frame_capture_native.dart consumes (commonFormat, sampleRate, channels, data as Uint8List, plus frameLength for parity with Android).

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🔍 Potential use-after-free race between RemoveSink and concurrent OnData callback

In stopAudioRenderer (linux/livekit_plugin.cpp:446-452), the mutex is held while RemoveSink() is called and the renderer is erased from the map. However, if OnData is currently executing on the WebRTC audio thread when RemoveSink is called, the AudioRendererSink object could be destroyed (by renderers_.erase) while OnData is still accessing its members (e.g., format_, sink_). Whether this is safe depends on whether WebRTC's RemoveSink blocks until any in-flight OnData call completes. The existing VisualizerSink has the identical pattern (linux/livekit_plugin.cpp:365-369), so this is a pre-existing architectural concern.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[alfredobs97]

Good catch to scrutinize — I verified this against both audio delivery paths used by the desktop binaries, and the pattern is safe: RemoveSink blocks until any in-flight OnData completes, so the sink cannot be destroyed while OnData is executing.

Remote tracks (pc/remote_audio_source.cc, upstream WebRTC and the webrtc-sdk fork that ships the desktop prebuilts): RemoteAudioSource::OnData holds sink_lock_ while iterating sinks and invoking sink->OnData(...), and RemoteAudioSource::RemoveSink acquires the same sink_lock_. RemoveSink therefore cannot return while a delivery is in flight, and no further callbacks occur after it returns.

Local tracks (webrtc-sdk/libwebrtc, src/internal/local_audio_track.h): identical discipline — AddSink, RemoveSink, and OnData all take the same sink_lock_, with sinks_ RTC_GUARDED_BY(sink_lock_).

Corroborating evidence: the wrapper itself relies on this guarantee. AudioTrackImpl::RemoveSink (src/rtc_audio_track_impl.h) destroys the AudioTrackSinkAdapter immediately after rtc_track_->RemoveSink(...) returns. If the guarantee did not hold, every existing consumer — including the VisualizerSink that has been shipping on Linux/Windows — would already be crashing on stop.

Holding the plugin mutex_ while RemoveSink blocks is also fine: OnData never touches the plugin mutex, so there is no lock-order cycle.

As noted, VisualizerSink uses the identical pattern, so this PR intentionally keeps the two classes consistent. There is a separate pre-existing (and unrelated) subtlety shared by both classes — sink_/on_listen_called_ are written on the platform thread and read on the audio thread without synchronization — which would be better addressed as a follow-up cleanup touching both sinks rather than diverging here.

[CLAassistant]

All committers have signed the CLA.