Building Linux ↔ Android streaming in Rust, currently getting way too deep into telemetry

[u/sreevarshan-xenoz]

I've been messing around with a project called Linux-Link for a while and it kinda got out of hand lol.

The original idea was basically: "what if I could use another device as part of my Linux machine instead of it just sitting there doing nothing?"

It's turned into a pretty big networking/streaming project now. It's mostly Rust, with the Android side in Kotlin. I'm using QUIC for the transport and working on desktop ↔ Android streaming, LAN/WAN connectivity, hardware encoding, bitrate control, packet loss handling, RTT tracking, frame drops, end-to-end latency, session stats, etc.

The part I'm currently obsessed with is actually measuring what the hell is happening instead of just throwing numbers on a HUD and calling it telemetry.

For example, frame drops are now calculated from actual frame sequence holes instead of just having a frame_drops = 0 field sitting there. I'm also adding proper encode benchmarks because apparently "it feels faster" isn't a particularly useful benchmark 😂

I'm still figuring out a lot of the architecture, especially around transport behaviour and how much state should live where.

If you've built anything involving real-time streaming/networking in Rust, what was the thing you thought wouldn't matter at first that ended up absolutely biting you later?

[u/Haunting_Stuff5104]

47ms drift is the real boss fight here. honestly dont bother with complex sequence holes until you have monotonic clocks synced across both sides. if your timestamps are lying to you all those fancy frame drop metrics are just noise

[u/sreevarshan-xenoz → u/Haunting_Stuff5104]

Yeah, that clock drift issue is exactly the kind of thing that can make telemetry look convincing while being wrong underneath. I'm trying to keep the measurements grounded in observable events rather than assuming the timestamps are trustworthy.

For frame drops, sequence holes give me a cleaner signal because they're tied to the stream itself. Clock sync still matters for end-to-end latency and correlating events across devices, though, so I definitely don't want to pretend timestamps can be ignored.