add bounded buffer to audio_stream, and use 10 frames as the default

[xianshijing-lk]

No description provided.

[ladvoc]

question: Is there a good reason to define a custom async queue primitive here instead of using tokio’s bounded mpsc channel? One possible motivation seems to be providing a synchronous push method. If that’s the goal, mpsc::Sender::try_send already supports that behavior. In general, I’d lean toward using mpsc (or a wrapper around it) here since it’s lock-free, well-tested, and we already pull in tokio as a dependency—unless there's a specific behavior it can't offer.

[xianshijing-lk]

question: Is there a good reason to define a custom async queue primitive here instead of using tokio’s bounded mpsc channel? One possible motivation seems to be providing a synchronous push method. If that’s the goal, mpsc::Sender::try_send already supports that behavior. In general, I’d lean toward using mpsc (or a wrapper around it) here since it’s lock-free, well-tested, and we already pull in tokio as a dependency—unless there's a specific behavior it can't offer.

The custom queue is not mainly about synchronous push. It exists because we need overwrite/ring-buffer semantics from a synchronous WebRTC callback. tokio::mpsc::try_send covers sync push, but not the drop oldest behavior.

This is my understanding:
The difference is in libwebrtc/src/native/audio_stream.rs:127: the current queue is explicitly drop oldest, keep newest when full. That matches the public contract in libwebrtc/src/audio_stream.rs:34 and livekit-ffi/protocol/
audio_frame.proto:28: keep latency bounded for real-time audio.

tokio::mpsc::Sender::try_send only gives us synchronous non-blocking push. It does not give this overflow policy. On full, it rejects the new item. For audio streaming, drop newest is usually worse than drop oldest, because it
preserves backlog and increases effective latency.

Please let me know if that makes sense, I'd be happy to switch over to mpsc channel if that behavior is more desirable.

[ladvoc]

Got it, that makes a lot of sense. There are some specialized channel implementations that use lock-free ring buffers that offer this behavior; rtrb (not async) and async_ringbuf are good references for this. If the locking overhead here is acceptable, I’d stick with the current approach. Otherwise, it may be worth exploring something closer to what rtrb does.

[xianshijing-lk]

Got it, that makes a lot of sense. There are some specialized channel implementations that use lock-free ring buffers that offer this behavior; rtrb (not async) and async_ringbuf are good references for this. If the locking overhead here is acceptable, I’d stick with the current approach. Otherwise, it may be worth exploring something closer to what rtrb does.

I did some research on rtrb, that is a tiny, high performance lock-free ring buffer, thanks for pointing it out.

I changed the implementation to rtrb, and added some tests there.