TEL-439: measure media latency introduced by media pipeline

[hechen-eng]

No description provided.

[alexlivekit]

Not sure what to think. This reuses the same entry and exit pointer for all packets.

• If a packet gets lost (e.g. media processor hook crash), we will not measure that at all.
• If a packet gets delayed by 21ms, what will happen is the next packet arrives, and we'd measure both latencies from the arrival time of the newest packet.

Should be a good enough first go at this, but not necessarily a reliable score.

[hechen-eng]

• If a packet gets lost (e.g. media processor hook crash), we will not measure that at all.

This case should be tracked differently than latency IMHO.

• If a packet gets delayed by 21ms, what will happen is the next packet arrives, and we'd measure both latencies from the arrival time of the newest packet.

I don't think we want to measure latency per packet though. Per frame should be sufficient IMHO 🤔

[alexlivekit]

I don't think we want to measure latency per packet though. Per frame should be sufficient IMHO 🤔

Not sure I understand that sentence 😅 With audio, we only ever have 1 frame == 1 packet.
My point was the following scenario there:

• 0ms packet/frame 1 arrives, updated entryTime to 0ms
• 20ms packet/frame 2 arrives, updated entryTime to 20ms
• 21ms packet / frame 1 gets forwarded, now - entryTime = 1ms (incorrect)
• 22ms packet / frame 2 gets forwarded, now - entryTime = 2ms

[alexlivekit]

Another point where we might want to improve things is reading from network. Consider the following scenario:

• 0ms packet 1 arrives to UDP socket buffer
• 20ms packet 2 arrives to UDP socket buffer
• 40ms packet 3 arrives to UDP socket buffer
• 41ms packet 1 is read from socket buffer, entryTime to 41ms (incorrect)
• 42ms packet 1 is forwarded to SFU, now() - entryTime == 1ms
• 43ms packet 2 is read from socket buffer, entryTime to 43ms (incorrect)
• 44ms packet 2 is forwarded to SFU, now() - entryTime == 1ms
• ...

In theory we should be protected from this issue by virtue of the channel in RtpRead, but in practice we still run into this problem since we're only recording entryTime in the single-threaded and blocking rtpLoop. so basically, this effect already happens, but instead of the socket buffer it's the Stream channel.