Skip to content

Conversation

@anunaym14
Copy link
Member

No description provided.

@anunaym14 anunaym14 requested a review from a team as a code owner May 31, 2025 16:38
@anunaym14 anunaym14 marked this pull request as draft May 31, 2025 16:39
@anunaym14 anunaym14 requested review from boks1971 and dennwc and removed request for a team May 31, 2025 16:39
@anunaym14 anunaym14 changed the title fix(sampleWriter): handle dropped packets fix(sampleWriter): handle dropped packets & opus dtx May 31, 2025
@anunaym14 anunaym14 marked this pull request as ready for review May 31, 2025 19:10
pcm.go Outdated
var droppedPackets uint16
if !w.lastWrite.IsZero() {
timeSinceLastWrite := time.Since(w.lastWrite)
if timeSinceLastWrite > w.sampleDur {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe need to make this a bit more fuzzy? As it is written here, a write coming through after 19.99ms will not insert a silence packet in between. Guess, it is okay, but just something to thinking about a bit and see if some fuzz factor should be applied (for example anything over 90% of duration can be considered a full duration).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, added a 10% tolerance

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a comment in the specific commit. I may be reading it wrong, but it looked like an empty packet would not be inserted if the gap is 19.5 ms for a sample duration of 10ms.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, missed that it's an integer division, not float. Converting it to float and rounding it off to the nearest integer instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could add a dropped packet at 15.1 ms. I am thinking it should add a packet at > 19ms only. So, you would have to include that tolerance in the number of packets calculation too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm okay, let me adjust that

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fpushed, it should be correct now!

// If the return value is 1 byte, then the packet does not need to be transmitted (DTX).
if n == 1 && e.useDtx {
return nil
}
Copy link
Contributor

@boks1971 boks1971 Jun 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:TIL: I thought 1 byte should be transmitted to signal background noise level. I think I have seen 1 byte packets comes in to the server. But, libwebrtc mentions this also (https://source.chromium.org/chromium/chromium/src/+/main:media/audio/audio_opus_encoder.cc;drc=dfb49a410ff213451f72db8d792973550025033e;l=288). Where are the 1 byte packets coming from into the server? Have to check again if I am not remembering something properly.

Copy link
Member Author

@anunaym14 anunaym14 Jun 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe some clients are not negotiating dtx? meet.livekit.io does not seem to be negotiating it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JS SDK sample app does DTX. I think I checked with that. Will test out and check packet sizes with DTX enabled.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DTX packets (or the packet before DTX kicks in) is 1 byte when trying with JS SDK sample app (setting red: false in the demo app) and logging on SFU side. Puzzled what opus_encode returns and how that is getting sent. Definitely does not jive with opus_encode() doc or libwebrtc code.

@anunaym14 anunaym14 force-pushed the feat/skip-samples branch from 18d37fb to 1a044d5 Compare June 1, 2025 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants