Valve calls its fix for 300ms Steam Link frame gaps speculative, in a three-line beta
SteamVR's 2.18.4 beta carries three change lines, and Valve will not promise that the one PC VR streamers care about works. Valve's note of October 16 offers Steam Link a "Speculative fix for ~300ms gaps in frame delivery in some packet-loss situations", and speculative is Valve's own word rather than a summary of it.
Steam Link is the component the speculative fix is written against. Image: Valve
The other two lines belong to SteamVR itself: "Fix crashes at startup with certain games" and "Fix occasional crash when unblocking previously-blocked add-ons in VR settings". Valve names no games and no platform for any of the three.
This is the beta branch, and stable SteamVR is still 2.17.10, from a hotfix on September 18. The note signs off with Valve's standing warning that replies to it "are not tracked for bug reporting purposes".
The two SteamVR lines in 2.18.4 cover a startup crash and a crash when unblocking add-ons. Image: Valve
A 300ms gap is a long time to lose frames
A stream running at 90Hz expects a frame roughly every 11 milliseconds, so a 300ms hole is around 27 of them missing in a row, which is long enough to feel like a stall rather than a stutter. Valve puts the cause in packet loss, which fits the symptom for anyone streaming over congested Wi-Fi.
What Valve does not say is how the fix works, or how it was tested. A speculative fix is a change made against a plausible cause rather than a reproduction, which is why the word is doing real work in that line.
VRChat is one of the two titles the Vulkan assert was first reported in. Image: VRChat Inc.
One owner posted that 2.18.4 fixed his crash, then struck it out
The Vulkan assert behind the Error -203 black screen we covered on October 15 was the obvious candidate for a startup-crash fix. On October 17 at 09:41 UTC the owner who filed it wrote "Seems to be fixed with 2.18.4 on my end", struck that sentence through in the same comment, and added "Cancel that, this still persists with some titles, will update in a sec".
Four and a half hours later he settled on something less comfortable: "So, as it is right now, the situation with this issue is that it sometimes occurs, sometimes not." He attached fresh logs and minidumps taken on SteamVR 2.18.4 beta with Steam client 1792110651 on Nobara 44.
Nothing joins the two ends of that story. "Fix crashes at startup with certain games" describes a class of startup crash, while issue 1006 is a compositor abort during a running session, and Valve's single comment on the report is from October 10, when it quoted the two assert lines back from the reporter's compositor log.
Valve Index controllers appear in one of the three reports, paired with an original HTC Vive on the stable branch. Image: Valve
Three owners, and one of them is on stable
The assert has been reported by three owners, all on that one issue, which is the whole count. One of them hit it on stable 2.17.10 on CachyOS with a Radeon RX 9060 XT, at the same 71,100-byte transfer size as the original report, so it is not confined to the 2.18 betas or to one distribution.
His description of what it does is the part a streamer will recognise: the headset goes black, vrcompositor aborts and is not restarted, SteamVR carries on running as though nothing happened, and only a full SteamVR restart gets the picture back.
The report is still open with Valve's bug label on it. The previous beta, 2.18.3, brought the promised Linux VR fixes on October 10, and 2.18.4 is the fourth beta in the line. Anyone can opt into it, and on the Steam Link line Valve's caveat opts in with you.
