We tried the tools built for this, and they all worked in the loosest sense of the word. Latency was "fine". 4K was "kind of". And when a frame showed up late, nobody could tell you why, because the honest answer was that the frame went through 4 or 5 programs that were glued together and none of them was keeping score.

That last part is what pushed us over. You can't fix what you can't see, and you can't see anything when your hot path is someone else's black box.

So we owned the whole path

We rewrote it end to end, in Rust, on both sides of the Wi-Fi.

On the PC, the sender captures the virtual monitor with Windows Graphics Capture or Desktop Duplication straight into D3D11. A small shader turns BGRA into NV12 on the GPU. Then the frame goes into the NVENC SDK through FFI we wrote by hand. There's no ffmpeg in the hot path and no copy back to the CPU. The frame leaves the GPU as HEVC, AV1 or H.264 and goes on the wire.

On the TV, the app is native Rust too, a NativeActivity with no Java and no Kotlin. It hands the stream to the hardware decoder and puts the picture straight onto the TV's 4K video plane, with the MediaTek low-latency path switched on.

Between them there's a protocol we can read in one sitting. A 24-byte header, one small TCP stream for video, UDP for audio, and a stats channel coming back from the TV. Every frame carries the time it was captured, so the TV can say exactly where the milliseconds went.

Why Rust, really

People expect a speech about memory safety here, and sure, that's part of it. The bigger reason is that Rust let us write the scary parts once and trust them.

A streamer like this lives on FFI. D3D11, the NVENC SDK, WASAPI on the PC, MediaCodec and AAudio on the TV. Every one of those is a C API that'll happily let you hand it a dangling pointer at 60 frames a second. In Rust, the unsafe calls sit in small wrappers that we audit, and everything above them is ordinary code that the compiler checks for us.

It also kept everything small. The sender is a 1.4 MB binary. The tray app is Tauri with plain HTML, CSS and JS. We said no to Electron on day 1, because shipping a whole browser to move a desktop across a room felt like a joke.

How we measure

Owning the path only matters if you measure it, so every real-TV run goes in a run book. It logs fps on the TV, decode time, frame gaps, GPU load and the full capture-to-screen latency, which covers capture, encode, Wi-Fi, decode and display.

The rule is simple. Real TV, real home network, never a fake receiver on the same PC. We learned that one the hard way, because a fake TV on your own machine makes everything look fast and tells you nothing.

Here's where 0.3.0 landed on our test rig, a MediaTek MT5895 Android TV and an RTX 5070 Ti laptop on home Wi-Fi, with a moving test page full screen:

17.6 ms from the moment Windows hands us a frame to the moment it's lit on the TV. That's about 1 frame at 60 Hz, which is the number we cared about from the start.

The catch

We'll keep saying this until people believe us. If your network is trash, TunnelRez isn't for you. It pushes 40 to 150 Mb/s at a fixed rate with no padding, so a crowded 2.4 GHz band or a mesh node in the attic will show up on screen, and no codec on Earth can hide that.

If you keep a clean 5 or 6 GHz link with power save off, or better, a cable, it's built to outrun anything else we've tried. That's the deal, and we think it's a fair one.

Next up we're writing about audio, which turned out to be its own little war: 255 ms to 55 ms.

We got it down to about 55 ms, in sync with the picture. It wasn't one fix. It was 4 separate problems stacked on top of each other, and each one was hiding the next.

The setup

On the PC, the sender captures what Windows plays with WASAPI loopback. It ships raw PCM, 48 kHz, 16-bit stereo, in 5 ms UDP datagrams, which is about 1.5 Mb/s. Every datagram is stamped with the same clock as the video frames, so the TV knows which sound belongs with which picture.

On the TV, a small jitter buffer holds the audio, between 20 and 80 ms depending on how bumpy the network is, and plays it on a clock. It never plays based on how full the buffer happens to be, because a fill-driven buffer just grows and grows. Then the audio goes out through AAudio, Android's low-latency audio API.

That design was right from the start. The trouble was underneath it.

1. A blocking write gets the slow lane

Our first TV player pushed audio into AAudio with plain blocking writes. It's the obvious way to do it, and it works, and it's slow. The Android docs say it plainly if you read far enough: a blocking write() never gets a FAST track, so you get high latency and big bursts no matter what you ask for.

So we moved to AAudio's data callback. AAudio now pulls audio from us exactly when the hardware needs it, and that's what unlocks the low-latency path. Same buffer, same clock, very different number.

2. The error that wasn't an error

Then the sound got choppy. Every burst or so, the stream would reopen itself and you'd hear a tiny gap.

It turned out to be the ndk crate, version 0.9. It maps every non-zero AAudio result to Err. That's fine for most calls, but write and set_buffer_size_in_frames return a frame count when they succeed. So a perfectly good write of 240 frames came back as an error, our code did the sensible thing with an error and reopened the stream, and that happened after every burst.

The fix is a small helper that reads the "error" back as the count it really is. We pinned the crate at that exact version and wrote down why, because the day a fixed ndk returns Ok(count), that helper has to go, and a different version of the bug would bring the choppy sound right back.

3. The TV that silently says no

This was the big one. AAudio can run in exclusive mode with MMAP, where the app writes straight into the hardware's buffer. That's the fastest path there is, so of course we asked for it.

On our MediaTek TV, exclusive MMAP always fails. In logcat you can see GET_STREAM_DESCRIPTION return FAILED_TRANSACTION. The nasty part is what happens next. AAudio doesn't fail the request. It quietly falls back to the old AudioTrack path and hands you back a working stream that just happens to be about 100 ms slower, and it never even tries shared MMAP.

So now the TV app checks what it actually got. If an exclusive request comes back as anything but exclusive, it closes that stream and opens a shared one on purpose. In shared mode the AAudio service makes the MMAP buffer itself and shares its endpoint, and that works on this TV. Output latency went from 107 ms to 25 ms on that change alone.

4. The OBS silence trick

The last problem was on the PC, and it was sneaky. Windows only delivers loopback packets while something is actually playing. When the PC goes quiet, the packets stop. When sound starts again, the first real packet shows up with a timestamp that jumps, and the TV's delay estimate jumps with it. You'd get a little lurch every time audio started after a pause.

The fix is the same one OBS uses. For the whole stream, the sender plays digital silence to the device it's capturing. Nobody hears it, but Windows sees something playing, so loopback packets keep coming all the time, the timestamps stay one continuous line, and the audio engine never goes idle. If that silent stream can't run, the sender falls back to sending its own silent datagrams on a 5 ms timer, in the same time base.

Where it landed

Stack those 4 fixes together and the audio goes from about 255 ms behind to about 55 ms from capture to played on the TV, locked to the picture the TV is actually showing. The play delay follows the video, so sound and frame land together instead of racing each other.

We also gave it a virtual "TV speaker". While you stream it becomes the Windows default, so you're capturing a clean device and your real speakers stay quiet, and when you stop, your old defaults come back.

What we took from it: check what the API actually gave you. AAudio handed us a slower stream without saying so, the crate reported success as an error, and we only caught both by measuring when the sound came out of the TV.

If you want to know how we got the picture fast in the first place, that's in Why we rewrote it in Rust.

That's TunnelRez Remote. It's a written spec right now, and we haven't built it yet. We want to show you the plan before it ships, because how it's built matters more than the fact that it exists.

The idea in one line

You run the relay, in your own Cloudflare account. We don't run a server in the middle, and your stream never touches anything of ours.

How it works

The relay is a Worker template you deploy yourself, with a "Deploy to Cloudflare" button or a plain wrangler deploy. It's small, and it does 3 jobs.

• A room. One Durable Object per owner keeps a WebSocket open for each device that's online. It uses hibernatable WebSockets, so a TV that's sitting there waiting costs you almost nothing.
• A device list. D1 holds your devices, their public keys, invites and an event log.
• TURN credentials. For networks that won't let 2 devices talk directly, it mints short-lived credentials for Cloudflare Realtime TURN for each session.

The Worker only carries small JSON messages for presence and the handshake. Video and audio never go through it, because Workers can't relay UDP and we don't want your stream depending on a Worker's CPU limits anyway. Media goes over QUIC on UDP, either straight from device to device or through TURN, encrypted end to end.

2 people, 2 places

The setup is built for the real case, where the person at the TV and the person at the PC aren't in the same house.

You add a TV on your relay's admin page and it gives you a one-time invite. It's 8 characters with no look-alike letters, it lasts 24 hours and it works once. The person at the TV types the relay address and that invite with the remote, or runs one adb command if they're the type. The TV makes its own key pair, enrolls, and shows "Connected to relay, waiting for a PC".

You add your PC the same way. Then you see the TV in the app as waiting, busy or offline, and you press Connect.

By default the TV asks first. It shows that a PC wants to stream to it, and the person there answers OK or No with the remote. No answer in 60 seconds means no. You can turn that off for a TV you own.

The security part

Keys are made on the devices and only public keys ever reach your Worker. So if someone somehow got your relay's database, they'd get a list of public keys and no way into a stream. Every message to the relay and every enroll call is signed. The admin page sits behind Cloudflare Access.

Picking a path

There's a mode for each kind of network, and you pick it per TV.

Auto tells you which path it took, and the round trip it measured, on both the PC and the TV.

The same warning, louder

Everything we say about networks counts double here. The internet between 2 houses is the worst network you'll ever stream over, so Remote won't hit the numbers we get on a clean home link, and we're not going to pretend it will. When we have real numbers, they'll go in the run book next to the local ones, measured on a real TV like everything else.

We don't have a date yet. When it ships, it shows up in the release notes first.