[theomonnom]

What was wrong

AudioSource.clear_queue didn't stop a capture_frame that was still running:

• Audio kept playing after a clear. A frame longer than queue_size_ms played on (~310 ms past the clear for a 500 ms frame into a 200 ms queue).
• The next capture failed. A capture_frame right after the clear raised "failed to capture frame".

Both bugs were in rust-sdks.

What changed

• Bumps livekit-rtc/rust-sdks to fix(audio): clear_buffer stops captures in flight rust-sdks#1665, which fixes both. Re-pin to its merge commit once it lands.
• Adds tests/test_audio_source.py. It uses a local AudioSource and AudioStream, so no server is needed, and it covers both bugs. It fails on the released 1.1.20 and passes with the fix.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Théo Monnom seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[devin-ai-integration]

Note

Newer findings are available below. Devin Review posted a newer report on this PR, in addition to the findings presented here.

🔍 Devin Review: 1 flag

Not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)

[devin-ai-integration]

Devin Review found 1 new potential issue.

1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)

[devin-ai-integration]

🔴 Overlapping captures leak completion senders

When captures overlap while the queue is occupied, capture leaks a boxed completion sender on rejection. The native source refuses captures while another awaits space, so repeated overlaps grow memory without bound.

Learn more

A buffered native capture boxes a oneshot sender and passes a raw pointer to the C++ source. The C++ capture_frame rejects a capture if its queue lacks space or another completion callback is pending; it does not take ownership of the pointer on failure. The updated Rust error branch returns without reclaiming that pointer, unlike the preceding implementation. Concurrent calls through capture_frame can reach this branch, and each rejection permanently leaks a sender.

Example: With a 50 ms queue, one 500 ms capture holds the pending completion callback. Another capture begins before the next 10 ms tick, receives a native rejection, and leaks its boxed sender. Repeating this pattern continually grows the process's memory use.

Recommended fix: In NativeAudioSource::capture, reconstruct and drop Box<oneshot::Sender<()>> from ctx_ptr when self.sys_handle.capture_frame returns false. Keep the callback as the sole owner only after successful acceptance.

---

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

[xianshijing-lk]

lgtm