Performance degeneration / freezing / packet loss after some time

[JackD83]

After the streaming is running for some time time (10-45min and longer) an issue occurs that results in:

• bad visual quality (macro blocks)
• lost packages
• complete freeze of the client app

Stopping the client on the HMD and restarting it helps for a shorter period of time (5-10min) and then the error reappears . There have been several issue reports (#64, #54, #51, #6) and I'm trying to bundle all information and work done (#66) to find this bug so far.

What we know so far:

• Issue is most likely on the client (Quest) side. The encoded video on the server side looks fine
• Sound is not the issue, even with sound enabled, the issue appears, but later.
• Changing the video encoder settings on the server did not help (intra refresh, number of reference frames and encoder low latency profile)
• changing power management on the quest did not help
• Using h264 seems to prolong the time until the error occurs
• Its not a buildup in one of the queues (NAL or encoder frames), flushing them does not help
• Freezing was probably fixed by changing the encoder profile to low latency

[LibreGit]

You didn't mention that once the issue starts to appear, the Quest app cannot be paused / resume / stopped properly (with menu button) :

• The screen becomes black on resume (but sound seems to still work, so does tracking)
• In this state if you try to stop the Quest app from the menu, a crash message appears after a little while (either a few seconds after the app is closed, or when you try to restart it).

Like FingrMastr said in the other thread, this suggests strongly that a thread becomes overloaded/stuck in the Quest, preventing the normal behavior which is to restore the stream on resume, or to close the threads properly on exit.

[MPfaffe]

1. Is it possible to save the ALVR-server stream to a local drive? I would try to watch it with a media player within the QUEST (VLC-stream and Quest-local) and see if the QUEST reacts similiar to the ALVR-client.

2. Is it possible to let the ALVR-server stream pre-encoded (h.264/h.265) video? I would try to stream by ALVR a video encoded by seperate encoding software (with similiar parameter in resolution, fps, bitrate etc.) and see if the QUEST reacts similiar to the current ALVR stream decoding.

Is there a way to monitor the QUEST Hardware (CPU/GPU utilisation, RAM utilisation, Temperatures etc.) in some way?

[MPfaffe]

Did some testing and analysing (focused on the decoding performance of the quest, independant from ALVR streaming but results could also be valid for ALVR), and I think I found settings which should work without "performance drops after a time". The problem is the encoding was performed by "OBS Studio", so maybe some of the settings need some translation to ALVR-Server settings....

my conclusion is that following encode setup of alvr should be fine as a input for the oculus video decoder: encoder: Hardware NVENC videobitrate: 50000kb/s (50 mbit/s) audiobitrate: 64 coderprofile: "low latency+quality" (!!) color format: @nv12 color range: 709; limited scale filter: bilinear resolution: 2560x1440 (!!) fps: 72

Please try the mentioned encoder settings in ALVR.

Some more optimization to the settings color format, color range and scale filter could lead to better image quality. To drive native resolution to/with oculus quest without issues, it is much more complicated to achieve, regarding my theory (how the decoder works).

Paket loss could be a seperate problem but could also depend on the performance issue!

_some kind of log/notes, what I did: start log: Playback on Oculus with oculus gallery, video streamed by Win 10 DLNA

recorded scene: auto-gameplay in assetto corsa recording SW: OBS Studio Some parameters: OBS encoder: Hardware NVENC videobitrate: 50000kb/s (50 mbit/s) audiobitrate: 64 coderprofile: see following explanations color format: see following explanations color range: see following explanations scale filter: bilinear resolution: scaled output = basic resolution; see following explanations

Playback on Oculus with oculus gallery, video streamed by Win 10 DLNA OBS Hardware NVENC

first Step used a ALVR like stream 2888x1600 @72 fps by OBS studio @low latency+quality @standard priority (RTX 2080 ti was in a kind of energy profile in MSI afterburner) big freezes about half a second (many/all of them are also visible on PC video playback, ingame they were not recognized by me), framerate is lowering over time, at the beginning of the video is smooth framerate (on pc it looks not that smooth on 60 Hz display but constantly), audio was perfect all the time. Summary of Quest behaviour: no frequent "network paket loss"-style failures identified within 40 minutes of streaming, but frame rate seems to decrease over time.

Maybe the freezes where a result of writing performance to HDD (5400rpm) or the encoder does not like the MSI afterburner profile. --> Recorded now to more performant storage in writing (HDD 7200 rpm; SSD), use performance profile @gfx and tested: Big Freezes are gone with HDD 7200 rpm and performance profile for gfx.

--> some theories on working process on the HW decoder (snapdragon 835 specifications) and made some decisions for the resolution and framerate setup...

2560x1440 @ 120 fps by OBS studio @low latency+performance @NV12; 601; limited @high priority (RTX 2080 ti with high performance MSI afterburner profile) for long-term decoding for evaluation of performance drops in decoding (test canceled by my self) it's not smooth! ugly frametimes... looks like 20 fps

2560x1440 @ 72 fps by OBS studio @low latency+performance @nv12 601; limited @high priority (RTX 2080 ti with high performance MSI afterburner profile) for long-term decoding for evaluation of performance drops in decoding (test canceled by my self) it's not smooth! ugly frametimes... looks like 20 fps

2560x1440 @ 72 fps by OBS studio @low latency+performance @nv12 709; limited @high priority (RTX 2080 ti with high performance MSI afterburner profile) for short-term decoding for evaluation to get smooth video experience it's not smooth! ugly frametimes... looks like 20 fps The difference between "@nv12 709; limited" and "@nv12 601; limited" not further investigated!

2560x1440 @ 72 fps by OBS studio @low latency @nv12 709; limited @high priority (RTX 2080 ti with high performance MSI afterburner profile) for short-term decoding for short-term decoding for evaluation to get smooth video experience looks smooth!

2560x1440 @ 72 fps by OBS studio @quality @nv12 709; limited @high priority (RTX 2080 ti with high performance MSI afterburner profile) for short-short decoding for short-term decoding for evaluation to get smooth video experience looks smooth!

*2560x1440 @ 72 fps by OBS studio @low latency +quality @nv12 709; limited @high priority (RTX 2080 ti with high performance MSI afterburner profile) for short-term decoding for evaluation to get smooth video experience looks smooth!

Last three videos were visually very similiar!

--> tried *marked video setup for longterm video decoding for evaluation of performance drops in decoding: smooth all the time (32 minutes video playback), some very minor frame drops, very enjoyable!

end Log_

[TC-VR]

@MPfaffe Could you compile the APK and server for testing with those settings? Txs

[MPfaffe]

@TC-VR sorry, i watched today my first "C++ for beginners video" on youtube, but i can't compile yet :-D.

But I have some news for you after further testing.... I installed now the ALVR version "Experimental 1" to be more independent regarding the resolution of the video stream. But it turned out that every resolution (HEVC and H264; tried 603x336 up to 4256x2352 , at 60 or 72 Hz and 50 mbit/s leaded to performance decrease and sometimes to freezes of the client.

BUT! Than I tried 4256x2352 ( HEVC 175%, 72 Hz, 100 mbit/s (was ingame locked to 60 fps... I assume the nvidia encoder limited) and there were no performance decrease over time (30 minutes tested)! And nearly no packet loss! Also at 150 % HEVC resolution @72 Hz @72 fps gameplay (auto gameplay, can't say anything about movement latency ;-) ) there were no problems.

So at the moment I recommend to use at least 100 mbit/s videostream. (for stability in case of good network setup/performance)

I could imagine there is something going on with the network performance if it is "bored". Maybe something switches to a lower network performance mode after a time and then the high latency confuses the ALVR-Client...

Currently I tried to switch off some energy suspension modes of my gaming PC: ethernet card , set highest Performance in Win 10, set highest performance in the Nvidia setup programm and also I disabled a setting "WMM APSD" in my router. But with 50 mbit/s videostream the performance decrease always after about 15 minutes...

[JackD83]

@MPfaffe thank you for testing!

The quest has an OLED panel with 2880 x 1600 resolution. Thats why we use it. Using a lower resolution will cause a blurry image. The used preset is "NV_ENC_PARAMS_RC_CBR_LOWDELAY_HQ" which is recommended for low latency application. Color format is nv12 for Windows 7 and RGB for 8 and 10. I have no idea why?! I forced nv12 on my Windows 10 and had no issues or bad image quality.

Is anyone using an AMD card?

Problem for me is, that I rarely get the issues at all. I played 1,5h Fallout without issues with settings others get problems after 10 min. Has someone a game that triggers the problems very fast?

[TC-VR]

@MPfaffe thank you for testing!

The quest has an OLED panel with 2880 x 1600 resolution. Thats why we use it. Using a lower resolution will cause a blurry image. The used preset is "NV_ENC_PARAMS_RC_CBR_LOWDELAY_HQ" which is recommended for low latency application. Color format is nv12 for Windows 7 and RGB for 8 and 10. I have no idea why?! I forced nv12 on my Windows 10 and had no issues or bad image quality.

Is anyone using an AMD card?

Problem for me is, that I rarely get the issues at all. I played 1,5h Fallout without issues with settings others get problems after 10 min. Has someone a game that triggers the problems very fast?

So this is with the released v7 experimental? Using ffr @ 50mb/s? Ik Will give it another shot with Skyrim and ED.

Txs!

[JackD83]

@TC-VR No, current experimental + some small changes on the client

[MPfaffe]

@TC-VR my latest tests were performed with experimental v1

@JackD83

The quest has an OLED panel with 2880 x 1600 resolution. Thats why we use it. Using a lower resolution will cause a blurry image.

I'm aware of this behaviour, but I imagine that feeding the Quest-decoder with higher resolutions than 2560x1440 @72 fps can lead to some issues. The most detailed information on Qest-decoder capabilities/modes found in the web:

The DPU is capable of outputting 2160p60 video with 10-bit color to a wide color gamut 10-bit internal or external display, although we have not seen any 10-bit panels for mobile devices yet. The DPU also supports Q-Sync, which allows a Q-Sync capable display to refresh as quickly as the GPU can render frames. Snapdragon 835 can also decode H.264 (AVC) and H.265 (HEVC) video at up to 2160p60, 1440p120, or 1080p240.

my Interpretation: --> I can imagine resolutions higher than 1440p (2560x1440) will be decoded only frame by frame (max 60 fps). Resolutions up to 1440p (half the pixels of 2160p) could be decoded with max 120 fps by decoding in a partly parallel and half-frame delayed way.

-->but the decoder seems not to be strictly limited to these supported modes/specifications as current Tests and common use of ALVR showed:

• Resolution 4256x2352 @60 client fps (@100 mbit/s) --> resolution is definitly not within the specification/supported modes but worked without performance decrease. The computing of the additonal pixels should lead to higher torture to the hw-decoder as with specified/supported settings.
• Resolution: 2880x1440 @72 fps (@ 50 mbit/s) --> performance decrease after some time (in my case 15 minutes with assetto corsa), sometimes freezes (I think it's a combination of an event in the network performance, maybe in combination with high torture to the decoder)

-->in my opinion the decoder could potentially handle 2880x1440 @72 fps not in one compute cycle but in two within performance-specification but maybe the way it has to proceed is not supported/realized. (some kind of parallel/delayed/partly-picture computing :-D)

My current assumptions/conclusion (just thoughts and theory):

• at the moment: if the decoder computes at higher resolution than 1440p @72 fps, it could lead to additonal aging of the decoder HW and to computing failures due to use over specification/supported modes (like an overclocked CPU). --> recommenation: use resolution =< 1440p for vidoeo decoding @quest @72 fps. "2560x 1422" (try to use this setting vor encoded video) is about the same height/width ratio as 2880x1600 (quest native resolution).

• I believe the major reason of instability is something within the network The performance decrease and Client freezes also occur @Resolution 603x336(!) @1mbit/s (!) after 15 minutes (!), but there are no (!) problems @about 4k resolutions @60/72fps @100 mbit/s .

"100 mbit/s" could be some kind of threshold.... e.g. pc ethernet adapter support modes: 1000/100/10 mbit/s --> maybe e.g. after a while with 50 mbit/s streaming, network adapter switches operation modes from 1000 mbit/s to 100 mbit/s (because it is enough for 50 mbit video streaming and leads to saving energy) but maybe with bad effects to network latency --> maybe it could lead to errors within ALVR Client...

As I said... just thougts and assumptions

[TC-VR]

@JackD83: could you compile your latest experimental? I would like to test it on my system. The released experimental V7 crashes after 10-15 minutes of Google Earth. Prior to that, image (with FFR slices) looks bl*dy brilliant and tracking is like native Rift S tracking.

Edit: nevermind; I installed Visual Studio 2019, Cuda 10.1 and Android Studio 3.5.1 and made the build myself :-)

[andy-d1969]

You don't need to set a higher resolution on the client to get a sharp image. The screen is not fully used. The default resolution of the Quest is 1216x1344 per eye. Oculus Home and most games are using this resolution. Some games like Red Matter are using an even lower resolution and the image is not blurry. I patched the ALVR client to set 1216x1344 as the fixed resolution and then i set 150% for supersampling on the server and the image is super sharp.

[TC-VR]

I just compiled from the main experimental branch, both client and server. I ran it at 1440x1600 and have selected 100 MB/s. FFR Slices. Steam VR at 100% displaying 1440x1600:

• The Lab: 30 minutes, 79 packets lost, constant 72FPS server and client side, no freeze, very sharp image, Total Latency no higher than 66 mostly round 62

• Skyrim: 25 minutes, 105 packets lost, Server: 72/ Client 71-72, SS maxed out in-game, no freeze, very sharp image (in Fovea area, bottom as expected blurry when in menu and peeking bottom and top FFR slice, not so apparent left and right slice). Colors are very good (a lot better than Rift S).

@JackD83 : Maybe you could recompile V7 for release? Is it possible something went wrong with the compilation of this build at the time? Here's my build attached. ALVR_EV7_20191030.zip

[TC-VR]

@andy-d1969 I will try your settings for comparison... txs

[Digeeboy]

@TC-VR I'm getting an error starting the windows client.

[Digeeboy]

I'm on Win10 64 pro with a GTX 1080 ti

[Kuuko-fokkusugaru]

I would like to add a note and it's to not forget that not everyone have those "bugs" so we should be careful of what it gets fixed at client side because if it works for most people and fixeds are added it could lead to break for some others. So to assume that the bugs it's only on client side it's a bit mmm "dangerous?". Quest it's a very closed system so if the client were that buggy it's more likely to not work for anyone at all. Isn't like we can install or mod that much settings there. So whatever bug it's causing the poor performance and freezes it may be related with either server side or a combination of server and client but rarely only the client. I use v7 experimental everyday and it works flawlessly. The only issue it's that sometimes, for some weird reason, I get returned to HOME and I need to open the app again through unknown sources but then the app it's like still running. I mean, is not like it closes and I need to open it again and connect, it's more like it goes to background but I can't return to it untill I reopen it.

[Digeeboy]

jackd83 made this comment to a build done by @LibreGit with a similar error

Builds made with the latest Visual Studio version require the latest vc runtime

[TC-VR]

jackd83 made this comment to a build done by @LibreGit with a similar error

Builds made with the latest Visual Studio version require the latest vc runtime Indeed, you could install cuda 10.1 and visual studio 2019 (free). This will install all latest dll's and drivers...

[JackD83]

@andy-d1969 I have to disagree. Using any other resolution as the panel resolution will result in a scaled image. How well it will be scaled depends on the display and other factors. The lower resolution of home and other games is due the fact that the quest is not capable of keeping the frame rate and they have to compromise. We are rendering on the PC. That's why I chose the panel resolution as default.

If you do want to use a lower transmitted resolution, you don't need to patch anything. Just use the video resolution setting in alvr.

@all please keep this thread about the performance issue

[andy-d1969]

But the image is rendered to a distortion corrected texture that does not fill the whole screen so it will be scaled. And afaik you are setting the resolution of this texture not the screen resolution itself. Maybe the resolution is too high for the decoder and this is the reason for the performance issue.

[Kuuko-fokkusugaru]

Hi everyone. I had a pending test and I am reporting back.

I finally could test on my Win10 machine which have the same hardware than the Win7 one.

I usually always play at 90MB/s 100% resolution without issues as I don't mind the bit extra of latency (mostly play VRChat) but for the test and seeing that some users report it to happen below 100MB/s, I used the usual 50MB/s 100% res no FFR. I played for like two hours without a single issue, total packet loss 74 with a latency of about 79.

So this is definitely not a Win10 related issue or at least not JUST due that but maybe a combination of Win10 with certain hardware/drivers. The thing is that has been already reported that using half duplex on the NIC fixed the issue besides the added bit of latency and those that had the issue on Win10 also had it on Win7 after installing it in a partition in the same machine.

So we would need way more info here to know the source. I guess the main issue it's debugging this it's quite hard unless you add some debug options to enable through the server which could make the client to create some log files that we could upload? I still think that the biggest hint here it's when @Susanoo1337 did the half duplex test and found that the issue was not there. I am not using such settings, my NIC it's set as automaic but tested at full 1Gb/s manully and everything still worked perfectly fine.

I don't think I have more tests to do but if someone has any suggestions or wants me to try something just let me know. Hope you guys can fix it soon but I feel it's tied to the way your GPU encodes or how the NIC/router handles all the data being sent. Being a Quest app problem would be weird since we all are using the same apk version.

[MPfaffe]

@KitsuneShan thanks for the post!

could you please give some information about your used NIC (type, descrete NIC-card?), Graphics card (type, driver version) and router (type and OS/firmwareversion)? Did you perform any changes to standard settings? Thank you in advance!

update!: it seems "VR chat" produces much additional network traffic according: "Easily 10GB per day if you chill in public worlds, upwards of 100GB if you excessively world hop, but as low as 1GB if you sit and stare in a mirror in 1-3 small private worlds (like the Box) with just a few friends."

Can you please monitor your network traffic during VR Chat gameplay (@50 mbit/s ALVR-stream) about 30 minutes? Are there sometimes peaks of about 100 mbit/s? (Monitoring e.g. by taskmanager in section performance/your NIC)

[Kuuko-fokkusugaru]

@KitsuneShan could you please give some information about your used NIC (type, descrete NIC-card?), Graphics card (type, driver version) and router (type and OS/firmwareversion)? Did you perform any changes to standard settings? Thank you in advance!

I have an i7 4790K, Asus Sabertooth Z97 Mark 1, 16GB RAM. I used to play with a 780Ti on the Win7 desktop at 60MB/s, 75% res, H264 just fine but it broke. On the Win10 desktop I had a 1060 3GB and just used ALVR once for a couple of minutes just to test the latency and if there were a clear difference between H264 and H265 but never long enough to test performance issues (the few minutes I played it was perfectly fine). Like a month or two the 780Ti broke and I got two 2080Ti for both desktops. With the 2080Ti I play, as I mentioned before, at 90MB/s, 100% res, H265 on the Win7 desktop. On the Win10 desktop I rarely play so I only have the 50MB/s test that I just did. My motherboard have two NIC, I use the Realtek one. Settings are the default one except for a few related with WOL that would make my desktops to wake from sleep. The nvidia drivers on the Win10 desktops are up to date, on the Win7 one it's the same I installed when I bought the cards and didn't update yet as everything works fine so far.

I use an Asus DSL-AC68U that I had laying around after we switched to fiber as the only access point for the Quest. It's connected to the main router just like both computers through an enthernet cable. The Asus router uses the MAC filter so only the Quest and my smartphone can connect to it, it's set as access point using static HDCP, there is no encryption or any other protection besides the MAC filter and only the 5GHz WiFi it's activated which is also set at 40Mhz as recommended and with a channel set far enough from the main channel to avoid interferences since my main router also have 5GHz WiFi among 2.4GHz one (I use this router for all the rest of devices).

I don't change anything on ALVR except of what has been already mentioned, MB/s and the setting to activate the mic. The rest it's as default with default buffer size and no FFR enabled. I have also played Skyrim without issues on the Win7 computer for several hours. I didn't try on the Win10 one yet but I highly doubt that there would be any difference at all unless ALVR works perfectly fine for you using VRChat too.

There is just one detail and it's that, for whatever weird reason, my Win7 computer doesn't seems to reach more than 106MB/s of upload speed while the download speed reach the maximum provided. This does not happens on the Win10 machine so I guess this may be due firewall or whatever other Win7 issue/bug. I just never cared that much to fix it, it wasn't a big deal.

I didn't monitored the network performance yet, I may try to do so but I guess it would be faster to simply test a non online game directly. But remember, some people with the issue on Win10 had it on Win7 too once they tried. Another important data it's how they "fixed" it limiting the NIC to 100MB/s. This seems to indicate that may depend on each NIC performance and capabilities.

[MPfaffe]

@KitsuneShan thank you for your detailed reply!

I did some more testing regarding network behaviour, here the most interesting (realtek NIC, ASUS RT AC2900):

• I used ALVR (50 mbit/s) and parallel I streamed a video (70 mbit/s) to a device which is connected to 2,4 GHz wifi --> nothing changed, the performance decrease still occur after 15 minutes...

• I used ALVR (50 mbit/s) and parallel I streamed a video (DLNA WIN 10 70 mbit/s) to a device (WIN 10 Laptop) which is connected to 5 GHz wifi --> no performance decrease within 30 minutes! --> In my opinion this leads to the router (behaviour in using the 5 GHz) as the reason for the performance decrease! --> than I paused the video (Windows mediaplayer) on the laptop --> the performance decrease popped in immediately --> start playback again --> no performance decrease.

• I used ALVR (50 mbit/s) and parallel I transimitted big video files to the Laptop which is connected to 5 GHz wifi --> the performance decrease popped in immediately --> canceled the file transfer --> no performance decrease

[Kuuko-fokkusugaru]

@MPfaffe Have you checked if your router it's using Adaptive Quality of Service QoS? Because mine has such feature but I did turn it off. It seems to manage the traffic differently and let you choose which things gets priority: video streaming, gaming, file transfers, etc... this may be holding the video to be sent if it detects that it's eating too much bandwidth (only thing I could think). While other devices streaming media does not get affected by QoS in such manner, we don't know either how the router identifyes the traffic. Maybe due the way that ALVR and Quest works, routers does not think it's a streamed video so it changes it's priority or right the oposite and it does indeed detects that it's a video and it's giving priority to something else. Who knows. Also, why would you assume it's the router itself and not the NIC doing all that?

I don't understand your last point. Wouldn't canceling the transfer of those files set it back to the default scenario where you are just simply using ALVR streaming to Quest?

[MPfaffe]

I don't understand your last point. Wouldn't canceling the transfer of those files set it back to the default scenario where you are just simply using ALVR streaming to Quest?

Yes, I assume it's the same scenario. After one minute I turned on the file transfer and saw the performance decrease for one minute, then I turned the file transfer off and then the fps went back to relative stable 72. After that happend I stopped the test, i think after further 10 minutes gameplay the performance would have dropped again.

Two weeks ago I tried to change some settings of the router (I think because of frequent packet loss in ALVR, but hard to remember), this includes also QoS, I think I turned it off because it improved things. But I will take look on it at sunday again. Thanks for the advice!

Also, why would you assume it's the router itself and not the NIC doing all that?

I assume this because the Test behind the first two points should be the same network traffic for the NIC, but with different results. The first test shows that there is no effect in streaming an additional video from the ALVR PC to the 2,4 GHz wifi (Quest was always the only device in the seperated other SSID 5 GHz wifi). The second Test shows if there is a second stream (ALVR PC to a added second device) within the 5 GHz wifi (overall over 100 mbit/s) the performance decrease is gone. For the ALVR PC NIC both tests shall be equal.

Does someone know how large the data transfer of ALVR is, besides the video stream? E.g. Audio (same stream or separate?), Position data... (additional data). And how is it transferred between PC and Quest? Is it more like a stream (stable bitstream) or like a file transfer (transfer on-->transfer off --> next file)

I could imagine that both, ALVR videostream and additional ALVR data, stay against each other in the routers priority decision. The router doesn't know that it is for the same application and need same priority. (I keep in mind that audio and tracking are still fully alive, if the performance decrease or freezes occur!).

[MPfaffe]

I still think that the biggest hint here it's when @Susanoo1337 did the half duplex test and found that the issue was not there.

Thank you for the hint I could imagine that it helps, as the video and most of additional data flows in the opposit direction (start/stop file like transfer of the video with buffering?)... i will try it on sunday! I have 100 mbit/s full duplex already tried, with no success.

[TC-VR]

This could be just coincidence but:

When playing Skyrim, one has to make sure that Steam VR room setup is set as Standing only. Then make sure when launching the VR server you reset your position by long pressing the Oculus button (this will recenter the Steam VR floor circle). I found out that when you're not in the Steam VR circle, all starts well but within 5 minutes of play, degeneration kicks in untill unplayable.

I played Elite Dangerous and used the seated Oculus room and never experienced any problems.

The experimental branch at the moment is very good, every other 20 to 30 minutes i'm getting a micro stutter (I gues GPU related) but definitely a very good and very crisp image. I just revisited "Blackreach" in Skyrim and it looks so good compared to Rift S, the colour reproduction on the Quest using ALVR is just plain insane! I'm realy hoping the Oculus link can provide a similar experience, if not, ALVR is just great AND unthetered.

[MPfaffe]

some more experiences in my cases (target bandwith 50 mbit/s):

-Activation/deactivation of the setting "QoS" in the router did not help. -Setting the NIC to "100 MBit half duplex" did not help. -then I tried some settings of the ALVR buffer and with 100 kB Buffer there were no (!) continues performance decrease @ 50 mbit/s. -then I tried 159 kb Buffer @50 mbit/s... and again there occured the performance decrease after a time.

This means: half the bandwith --> half the buffer 100 kb in buffer @50 mbit/s should be around one frame in the buffer. 200 kb in buffer @100 mbit/s should be also around one frame in the buffer.

maybe the buffer should be linked to the video bitrate setting and limited to around one frame?

[TC-VR]

@MPfaffe, I will thinker with this as well since I use 200 KB buffer with 100 Mbit/s and everything jus works whereas previously I used 40 and 50 Mb/s with a 200 kb Buffer and had problems as well. I changed it to 100 Mbit after I compiled again from the branch and no more degredation, except when i'm not in the Steam VR circle... very strange...

Maybe when outside the Steam VR circle, tracking en localisation datastream needs constant corrections/repositions between the Oculus bounderies and the Steam VR bounderies and gets priority over the video stream?? This would also explain when it's starts detoriating when I'm outside the circle, the image corrects itself immideately when standing still and gets a lot worse when moving controllers/hmd...

[Susanoo1337]

Hello again, I've been very busy recently so I couldn't spend any time on VR.

But here I am again, with some new results: The glitch seems to not be dependent on your NIC. I've finally gotten around to trying my Intel 82574L network chip in the other PC, and no issues arose. The entire gaming session (~1hour), until the ALVR app on the Quest crashed, had 0 packets lost. Running on 30Mbps with a 200kb buffer on Win 7. My other machine, Win 10 and 7, has under the same conditions, with the same NIC, experienced massive transfer degradation after only 11 minutes.

The last possible factor is the MB Chipset. The machine which can run ALVR flawlessly regardless of settings is using an antique Z77 chipset. Kitsune is using a Z97 chipset without problems.

My issues arise on the machine with a Z390 chipset.

Could you @TC-VR and @MPfaffe post your MB/chipsets, maybe there is a common through line somewhere here.

Other than that, the only other diverging factor I can exclude on my end is the GPU, my older PC has a GTX970ti and my newer has a 1660ti. I can swap the GPUs and see if the issue follows or remains.

[Kuuko-fokkusugaru]

@Susanoo1337 I am not sure if it would be tied to the GPU. In some ways it should be the biggest factor knowing that it's who it's enconding the video after all but before the 2080Ti, I used to play on a 780Ti which, even tho it has more CUDA cores and slightly better performance than 970, it's even older. With the 780Ti I had to use H264 tho as it does not supports H265. But I am sure you already tried with H264 just for the testing sake with same results. But that's the thing, 780Ti it's even older and it was fine. My only issue was due performance since gaming and streaming with these GPUs were not so optimized and you could notice easily the performance drop when streaming which made me play at 75% resolution (or with FFR) on VRChat to mitigate the fps drops a bit. Playing at 100% still worked tho, no performance issues on Quest side besides the in game performance itself.

[TC-VR]

• Gigabyte H370 HD3 => Intel H370 chipset
• Intel i5 8400 cpu,
• 16GB DDR4 ram,
• Gigabyte Nvidia GTX1070 8MB
• Network : Gigabit Ethernet (Intel® GbE LAN),
• WIFI AC Router 5Ghz, placed in line of sight, computer connected via ethernet to router, connection speed 867 Mbs

[MPfaffe]

my sys: AMD Ryzen 7 1700 Asrock B450 pro4 (AM4; B450 chipset) 32 gb DDR4 RTX 2080ti onboard NIC: realtek 8168h router: ASUS RT AC2900

[ghost]

I'm using h264 65mbps. Buffer size is 708kb and sliced ffr on. Client frequently micro stutters but it never gets noticeably worse, although it is clear it is not butter smooth most of time. I can see client fps dropping to 50-60s. I am seeing 500 packet losses in 2 hours or so of constant use. The client crashes once in an hour or more rarely. V6 and v7 didn't make difference for these issues for more, at least it is nothing extreme anymore in my case like it used to be.

[MPfaffe]

@Susanoo1337

The entire gaming session (~1hour), until the ALVR app on the Quest crashed, had 0 packets lost. Running on 30Mbps with a 200kb buffer on Win 7. My other machine, Win 10 and 7, has under the same conditions, with the same NIC, experienced massive transfer degradation after only 11 minutes.

On the win 7 machine, the FPS are stable at 72 until it freezes? Is in both cases the same router used?

Maybe when outside the Steam VR circle, tracking en localisation datastream needs constant corrections/repositions between the Oculus bounderies and the Steam VR bounderies and gets priority over the video stream??

Are both virtual boundaries dependent of each other? Additional data transfer besides the videostream could maybe lead to some kind of priority decision with advance to the additional transfer...

Further experiences, which could correlate with the performance decrease issue: -After performance decrease occurs, then I stop the ALVR Server and start the Server again with same settings --> the ALVR client freezes. But if I start the Server again with different Codec (h264 <-> h265), it works again until the performance decrease occurs after a time... -after freezed ALVR client, I stop the ALVR client over the oculus home button. Then I reopen the ALVR client and it says the application has stopped... it seems that after freezing of the client and closing of the client, the client still runs in the backround.

Maybe off-topic: using the h265 codec, there were several "flashing" images during gameplay... I didn't recognized that on h264

@T3ER Could you please give some info of your system?

[gunnarweibrink]

@JackD83 : Maybe you could recompile V7 for release? Is it possible something went wrong with the compilation of this build at the time? Here's my build attached. ALVR_EV7_20191030.zip

Hi TC-VR,

followed this topic and I think, you are on the right way!

After doing dozens of tests, friggeling with router settings and experimenting with ALVR, this Post frome you comes up. Deleting the configration under %LOCALAPPDATA%\ALVR and start from scratch up. Don't know, if it's with this build, but in the meanwhile, die ALVR Server "hangs"... showing the HMD disconnected, but everthing works as it should! Crazy...

Anyway, I also recognized the advises to 100MBit/200kb and 50MBit/100kb and tried with these settings - and it works! I also activated FFR "Slice" (other stettings default) with no visual degration - fantastic! Didn't touch any other settings beside "launch SteamVR without Steam", which should not matter at all.

My system specs:

• i7 4770S with 16GB of DDR3 on ASUS Z-87A
• nVidia RTX 2800 (single ;-)
• Win10 x64 Pro 1909

Settings of ALVR (to be precise ;-)

• Bitrate 30MBit > 50MBit/100kB (alternative > 100MBit with default 200kB)
• FFR > Slices
• Launch only SteamVR... > ON

And it gave me a wonderful image, rock-stable perfromance (no frame drops, as I can say ;-) and without performance degeneration or a complete "hang" of the Quest-App. For the first time...

Many thanks for your effort and your investigations (also for the help of all others). Souch a community is "the best of the quest" :up:

Gunnar

[TC-VR]

@gunnarweibrink Indeed, I did just the same thing: 100 Mbit/200kb AND 'Launch only SteamVR... > ON' and also I quit the nvidia experience service.

And you are right, because of the current stability my 'tests' usually end up in over an hour play sessions ;-) and when I want to print screen the server window, it always shows 'HMD not found' but everything just works and keeps working.

Little tip to increase the resolution even more:

After you launch the Steam VR server (with Quest client running), go to the Steam VR settings and

• check the 'Custom Resolution' box in video settings (mine is calculated at 144%)
• set the individual applications video sliders to 100% for each application
• Restart Steam VR

Stunning image quality, no stutter and no packet loss... Skyrim looks amazing and Google Earth VR is to die for. Pavlov VR feels nearly as native as the Quest variant but the visuals!

Glad to help, but really: it's @Polygraphene and @JackD83 that have been doing the heavy lifting.
But thanks to the testing of @MPfaffe, @Susanoo1337 and @KitsuneShan and all others I arrived at this point where I'm not really sure that Oculus Link will be worth our while ;-)

[MPfaffe]

@gunnarweibrink everything with a "buffer to videobitrate ratio" of about "2" works (videobitrate in Mbit/s, buffer in kB) --> possible alternatives: 60 mbit/s @ 119kB; 69 mbit/s @138 kB, 79 mbit/s @157 kB.... and so on. Increasing the Buffer @those Bitrates leads to performance degeneration and freezes. Decreasing the Buffer @those Bitrates could lead e.g. to more frequent pixelated images.

It was a pleasure for me to test and I am glad to achieve some helpful results! But it is a bit disappointing not to find the reason for the issue...

The big target is to help improving the ALVR application more and more! ;-) Thanks to all who are participating in improving ALVR! In my opinion it is a great software for VR in general!

[TC-VR]

It was a pleasure for me to test and I am glad to achieve some helpful results! But it is a bit disappointing not to find the reason for the issue...

The big target is to help improving the ALVR application more and more! ;-)

Thanks to all who are participating in improving ALVR! In my opinion it is a great software for VR in general!

Amen to that! Ik also have Virtual Desktop and I would reckon that with the combined efforts of Polygraphene, JackD83 and ggodin (VD), the Quest would become thé VR headset to beat for months to come. The current ALVR still has a big edge over Virtual Desktop but the last beta has closed the gap somewhat. Still a lot of work

[gunnarweibrink]

I'd copy that!

Indeed, I did just the same thing: 100 Mbit/200kb AND 'Launch only SteamVR... > ON' and also I quit the nvidia experience service.

Those services are never active, because "GeForceExperience" isn't installed... as always.

everything with a "buffer to videobitrate ratio" of about "2" works (videobitrate in Mbit/s, buffer in kB) --> possible alternatives: 60 mbit/s @ 119kB; 69 mbit/s @138 kB, 79 mbit/s @157 kB.... and so on.

But this can be a good workaround, even for ALVR itself. Jut put a "link" button beside the slider which synchronizes these settings as shown by you. If somebody would like to "experient" with these, it can be deactivated.

Also FFR with "Slice" should be default ;)

Great people here! Gunnar

P.S.: but what is the "special" about your build, TC-VR? ah, I see... you've compiled the latest sources... beyond Ev7.

[MPfaffe]

I recently experienced some similiar behaviour to the freezing issue of the ALVR client. It happens at the beginning of the game "pistol whip", when the game and scenes are loading, but in this case it is only temporarly. Once the game/scene is loaded the issue does not occur furthermore.

My question: Does the ALVR client write/read anything to/from the quests "harddrive" or only to/from RAM?

[JackD83]

@MPfaffe the client should not freeze at all. Are you sure it's the client that freezes and not the server rendering the game? Some games like fo4 drop back to steamvr loading screen if I save the game.

For the performance issue, I can tie thx buffer to the video Bitrate if this solves this issue. There is already a calculation for the sending part that is based on the video and audio bitrate

[MPfaffe]

@JackD83

Are you sure it's the client that freezes and not the server rendering the game?

First I have to say I'm still on experimental 7, maybe the freezing issue is already fixed within the current source code. Following events are in my opinion evidence for the client's freezing/beiing not responsive and server is still working:

-after freezed ALVR client, I stop the ALVR client over the oculus home button. Then I reopen the ALVR client and it says the application has stopped... it seems that after freezing of the client and closing of the client, the client still runs in the backround.

• during "only" performance degeneration, it is the same behaviour
• during "only" performance degeneration, if pressing the oculus button to exit the application and resume by pressing again, the screen is just black
• during performance degeneration/freezed state, closing the client, the server seems still working (see "Furthermore"). After a while (about 30 s), there is a notification in the quest that the application has stopped and with that the network traffic is vanished.
• before performance degeneration starts, if closing the application on the quest the network traffic vanishes immediately.

--> it seems the alvr client is not responsive in case of performance degeneration/freezed state

Furthermore:

• during freezed state (stand still video output on quest) of the application, the network traffic of the video is still there (task manager)
• during freezed state of the application, the VPU utilisation of the graphics card is still there and refreshing (according NVidia Inspector)
• during freezed state of the application, the alvr server continues sending the data; "encoding latency" and server FPS are still refreshing; transport latency, client FPS and decode latency are not refreshing/there seems to be no feedback of the client (ALVR Server diagnosis, sometimes the connection between server and client is lost)

-->server side activities seems working, no feedback of the client to ALVR server diagnosis

Some games like fo4 drop back to steamvr loading screen if I save the game.

I remember some statements that FO4 was full of bugs, also regarding saving and loading savegames. In your case the client seems still to work properly at steam vr home screen/dashboard.

My question: Does the ALVR client write/read anything to/from the quests "harddrive" or only to/from RAM?

Just want to ensure that the videostream is not "accidentally" transfered to the flash storage of the quest :-D

[FingrMastr]

I apologize for my absence in the last weeks. I’ve a company to keep running so...

I did a little discovery. I tried 5 different WiFi routers, with the exact same topology, wired ethernet connected to pc, WiFi 5ghz ac-only connected to quest. Also, I tested with Elite Dangerous in the exact same conditions. I discovered that using two of them there is no performance degradation. Two TPLink, one Technicolor, one Linksys, one netgear. Here are the models and results:

TPLink Archer M200 - performance degradation TPLink Archer M600 - performance degradation Linksys AC1750 - performance degradation Technicolor TC 582 - NO performance degradation Netgear R7000 - NO performance degradation

So, I think network jitter is involved.

Hope this helps...

[TC-VR]

I use this acces point: Compal CH7465LG (provided from my ISP as a network Wifi booster). It's supposed to be based on the Intel Puma 6 chipset (with a bad rep when it comes to jitter...)

But, then again, afer I recompiled from the main experimental branch and since I play at 100 MB/s with 200 kb Buffer, I haven't experienced packet loss nor freezing!!

Skyrim It really is amazing to be able to play Skyrim (@144% video setting in Steam VR and maxed-out super sampling in-game). The visuals are (thanks to a couple of mods) just amazing. I've been playing at least 20 hours now without a single hiccup or freeze. I will record a video from within the Quest to show you guys how sharp teh image really is: no artefacting and no washed out or blurry textures, shifts,... you have to see it to believe it... Virtual Desktop in it's current state on the insane settings still gives bad visuals...

Elite dangerous It's just an awesome experience (much better with the Quest and ALVR than with the Rift S thanks to the vivid oled screen colors and deep blacks) The Rift s 'might' be a hair sharper, but i'm having a blast (using a X52 Pro and Voice Attack).

Pavlov VR Great visuals, no artefacting, just the input lag will kill you ;-). The tracking is pretty close to the Quest Version but the lag is noticable.... alas...

I really wonder if the Oculus link can top my ALVR experience... Unthetered for a bit of tracking lag... I'm fine with that...

[LibreGit]

@TV-VR Happy to see that it's working great for you. The buffer tuning is something I have to try too.

It's really good if it can prevent the performance degradation and freezing to even appear. Still the weird part is that when it appears it seems to put the App in such a buggy state that it cannot recover unless you restart it.

About Oculus link, ALVR still needs a sliced encoding implementation to lower the total latency and be closer to a tethered experience latency I think.

The best would be to have a slider to choose the number of slices you want for each frame, so people could finely tune it (because the more you have the lower the total latency will be, up to a point, but the smaller each slice is, the less efficient the encoding, so the total bandwidth and processing power needed will also raise a little bit)

[gunnarweibrink]

@TC-VR:

But, then again, afer I recompiled from the main experimental branch and since I play at 100 MB/s with 200 kb Buffer, I haven't experienced packet loss nor freezing!!

Just to be sure... you referring to the "ALVR_EV7_20191030.zip", you've posted here? Or is there a newer one?

Gunnar

[TC-VR]

Just to be sure... you referring to the "ALVR_EV7_20191030.zip", you've posted here? Or is there a newer one?

Indeed, still using the ALVR_EV7_20191030 version.... just to be on the safe side, I would advice to install Visual Studio 2019 and Android Studio so you get the latest Microsoft runtimes... But the game changer for me has been

• Make sure you're on the 5 GHz WIFI AC band (I always turn the Wifi off and on in the Quest prior to starting the ALVR client)
• Set Bitrate to 100 MB/s, leave the video slider on 100% (initially it always displays 2432x1344) and set the Buffer Size to 200 KB. All supersampling is done in Steam VR and/or in-game

I used to program in PHP but haven't touched a piece of C-coding in quite a while (20 odd years I guess). Nonetheless, I will try to program a slider which will link the buffer with the bandwidth and recompile...

My Settings

[Kuuko-fokkusugaru]

@TC-VR why the sent rate shows 20mbps instead of 100? When I set mine at 90, it does send at 88-90 but yours seems way lower.