ALVR: Streaming SteamVR Games to a Standalone Headset Over Wi-Fi

What ALVR replaces, and who it is built for

The problem ALVR addresses is physical. A PC VR headset normally needs a cable to the machine rendering the scene, which limits where you can stand and how you turn. ALVR removes the cable by encoding each rendered frame on the PC and sending it over the local network to a standalone headset that decodes and displays it. The README describes the project in one line: stream VR games from your PC to your headset over Wi-Fi.

The audience is narrower than that sentence suggests. You need a supported standalone headset from the compatibility table, SteamVR, and what the README calls a high-end gaming PC. That PC must run Windows 10 or 11, or Linux. Windows XP, 7 and 8 are marked unsupported, and macOS is marked unsupported. The GPU requirement is specific: NVIDIA with NVENC support from the GTX 1000 series onward, an AMD GPU with AMF VCE support, or an Intel GPU with VPL support from Arc or Tiger Lake onward, all with current drivers. On a laptop with both an integrated and a dedicated GPU, the README asks you to assign the dedicated adapter to both ALVR and SteamVR.

This is a fork. The README states it is a fork of the original ALVR by polygraphene, and the Oculus Go row in the compatibility table points at that older repository instead. So the project you are reading about is the maintained continuation, not the first version.

The encoder, the socket and the client: how a frame gets to the headset

The repository is a Cargo workspace, and the member list is the clearest map of the architecture. `alvr_server_core` and `alvr_client_core` hold the two halves of the pipeline. `alvr_packets` defines the wire format. `alvr_sockets` handles transport. `alvr_graphics` and `alvr_audio` cover capture and encoding on the PC side. `alvr_session` holds session settings, `alvr_server_io` handles persistence, `alvr_events` carries notifications, `alvr_system_info` reads machine capabilities, `alvr_adb` talks to Android devices, and `alvr_filesystem` resolves paths. The workspace version is 21.0.0-dev14 and the crate edition is 2024 with a minimum Rust of 1.92, so the codebase is on a recent toolchain.

The practical consequence of that split is that the PC side and the headset side are separate programs that share a packet definition. The client is installed on the headset, either from a store listing or, for platforms without one, by sideloading through the ADB helper. The server runs on the PC and integrates with SteamVR. The `openvr` directory at the top level is the integration point with that runtime.

Network topology matters more than any code path here. The README recommends 802.11ac 5 GHz Wi-Fi for the headset and wired Ethernet for the PC, and requires both devices to be on the same router, or a routed connection as described in the wiki. That is a latency budget statement in disguise: the encoder cannot fix a congested channel, and ALVR does not claim to.

Installing ALVR from the launcher and pairing a headset

The README does not walk through installation itself. It points at a wiki installation guide, and it offers prebuilt launchers for Windows and Linux. The download links in the README resolve to `alvr_launcher_windows.zip` and `alvr_launcher_linux.tar.gz` on the latest release, so the launcher is the intended entry point rather than a manual build.

The README does give an uninstall procedure, which tells you something about what the installer touches:

ALVR Dashboard.exe

Open that executable, go to the `Installation` tab, and press `Remove firewall rules`. The README then says to close the ALVR window and delete the ALVR folder. Firewall rules are the part that does not disappear when you delete a directory, and the project gives you a button for them rather than leaving them behind.

For a first session, the sequence the README implies is: install the launcher on the PC, install the client on the headset, start SteamVR, and connect the two over the same router. The README does not document the pairing dialog, the port, or the discovery mechanism, so treat the wiki as the source for those steps rather than guessing. If you build from source instead, the README sends you to a separate build guide, and the workspace layout above is what that guide has to assemble.

Where ALVR fails: network, GPU and the headsets it dropped

The compatibility table is the honest part of the README, and it contains three different kinds of no. Lynx R1 is marked with a warning and a footnote saying it was temporarily removed and last supported on version 20.14.1. Android and Monado are marked with a warning tied to PhoneVR, which the README says works on some smartphones but has not been extensively tested. Oculus Go is marked with a cross and redirected to the old repository. If you own one of those, the current release is not the release for you.

The GPU requirement is a hard failure mode, not a preference. Without NVENC, AMF VCE or VPL on the card, there is no hardware encoder for the server to use, and the README lists the requirement without offering a software fallback. A machine that runs SteamVR fine can still be unusable for ALVR.

The network is the second failure mode. The README asks for 5 GHz Wi-Fi on the headset and wired Ethernet on the PC, on the same router. That rules out a lot of real setups: a headset on a 2.4 GHz band, a PC on Wi-Fi, a mesh network that hands the headset to a different node mid-session, or an apartment building where the 5 GHz band is crowded. ALVR is the wrong tool when you cannot control the access point, because the encoder has no way to recover from a channel that drops frames.

There is also a laptop-specific trap. On hybrid-graphics machines the README instructs you to assign the dedicated GPU to ALVR and SteamVR through the vendor control panel. Skip that and the server may run on the integrated adapter, which is not on the supported encoder list at all.

ALVR versus a wired link and versus Virtual Desktop

The obvious alternative is the cable. A link cable removes the encoder, the network and the latency budget from the problem entirely, at the cost of the tether. ALVR's whole reason to exist is trading that cable for a network dependency, so the comparison is not about quality in the abstract. It is about whether your room and your router can absorb the risk.

The closer alternative is Virtual Desktop, and the difference is architectural rather than cosmetic. Virtual Desktop is a closed application that handles streaming on both ends. ALVR is MIT-licensed source with a workspace of Rust crates that you can read, patch and build yourself, and the README links a build guide and a contributing guide. That openness is the real distinction: if the encoder selection, the packet format or the client behaviour is wrong for your hardware, ALVR is something you can change. With a closed streamer, you file a report and wait.

The cost of that openness is operational. ALVR expects you to know your GPU's encoder generation, to configure GPU assignment on laptops, to keep the PC and headset on the same router, and to read a wiki for installation, troubleshooting and Linux-specific troubleshooting. A closed product hides those steps behind an installer. ALVR puts them in front of you.

Licence, upgrade cost and what a version bump can take away

ALVR is MIT licensed, and the workspace manifest repeats that at the package level. In practical terms the MIT licence permits commercial and private use, modification and redistribution, provided the copyright notice and permission notice travel with the code. If you fork ALVR into a product, that notice is the obligation to keep. This is a description of the licence text, not legal advice; if the redistribution matters to your business, have someone qualified read it.

The README also states that ALVR apps do not directly collect any personal data, which is a short privacy claim and worth noting only because it is short. It says nothing about what the launcher or the client transmit beyond that sentence.

Upgrade cost is where the release history is instructive. The Lynx R1 footnote shows what a version bump can do: the headset was supported, then removed, and the README points users back to 20.14.1 as the last release that worked. Anyone on that hardware is pinned. The same pattern applies to the Oculus Go, which lives entirely in the older repository now. Before upgrading a working setup, check the compatibility table for your headset row rather than assuming the newest release is a superset of the old one.

The workspace sits at 21.0.0-dev14 while the newest release listed is 20.14.1, so the development line and the release line are not the same thing. If you build from source you are ahead of the released launcher, and the README's build guide is the only documented path for that.

Editorial conclusion

Adopt ALVR if you have a supported standalone headset, a wired PC with an NVIDIA, AMD or Intel GPU that exposes NVENC, AMF VCE or VPL, and a 5 GHz access point you control. Do not adopt it if you rely on macOS, a Windows version older than 10, or a headset the compatibility table marks with a warning or a cross, and do not expect it to work on a congested shared network. Before installing, read the wiki installation guide and confirm the exact GPU encoder requirement for your card, because the README treats that as a hard prerequisite rather than a recommendation.

Frequently asked questions

Official sources

1. alvr-org/ALVR on GitHub
2. Issues
3. License: MIT
4. README
5. Releases