Disabling rumble feature? #189

Closed
NeoToriyama opened this Issue Aug 29, 2016 · 23 comments

Comments

Projects
None yet
7 participants
@NeoToriyama

I was wondering if you can disable the rumble feature? I believe it to be one of the variables responsible for the "black screen" issue many users (like myself) are experiencing with the Vridge/Riftcat program and I need to do some more tests to that end.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 29, 2016

Hi, I don't know how to but noticed in many games if you have a Xbox 360 controller plugged in the rumble is made by the controller instead the psmove..

Anyone had similar experiences with Xbox or other peripherals?

ghost commented Aug 29, 2016

Hi, I don't know how to but noticed in many games if you have a Xbox 360 controller plugged in the rumble is made by the controller instead the psmove..

Anyone had similar experiences with Xbox or other peripherals?

HipsterSloth added a commit that referenced this issue Aug 31, 2016

Fix for issue #189 (Disable switch for rumble)
* Added support for a new "rumble_suppressed" flag in the steamvr.vrsettings file
@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Aug 31, 2016

Collaborator

I just published a release with these changes. I'm marking this issued as resolved BUT you shouldn't grab this new build until Issue #168 is marked as resolved. This new build breaks compatibility with PSMoveFreePieBridge due new code added for the DS4 in this release. hawinse already knows about this and has a fix waiting. Once he has a new build posted you'll want to grab that and then give this a shot.

If anything comes up please feel free to start a discussion on the newly opened forum: https://groups.google.com/forum/#!forum/psmoveservice

Collaborator

HipsterSloth commented Aug 31, 2016

I just published a release with these changes. I'm marking this issued as resolved BUT you shouldn't grab this new build until Issue #168 is marked as resolved. This new build breaks compatibility with PSMoveFreePieBridge due new code added for the DS4 in this release. hawinse already knows about this and has a fix waiting. Once he has a new build posted you'll want to grab that and then give this a shot.

If anything comes up please feel free to start a discussion on the newly opened forum: https://groups.google.com/forum/#!forum/psmoveservice

@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Aug 31, 2016

Collaborator

Oh I forgot to mention the rumble disable setting is described in the steam vr settings wiki page. It basically looks like this in your steamvr.vrsettings file:

   "psmove" : {
      "rumble_suppressed" : true
   },
Collaborator

HipsterSloth commented Aug 31, 2016

Oh I forgot to mention the rumble disable setting is described in the steam vr settings wiki page. It basically looks like this in your steamvr.vrsettings file:

   "psmove" : {
      "rumble_suppressed" : true
   },
@NeoToriyama

This comment has been minimized.

Show comment
Hide comment
@NeoToriyama

NeoToriyama Aug 31, 2016

Thank you! I'll be sure to test it asap.

Thank you! I'll be sure to test it asap.

@POEDaley

This comment has been minimized.

Show comment
Hide comment
@POEDaley

POEDaley Sep 28, 2016

Hello all, this post is in regards to the black screen issue that NeoToriyama was looking into.

Sorry for adding to an older thread, and I'm not entirely sure if this is the correct one to do so, but I found a bit more data on the black screen issue that I have not seen anywhere on any forum.

By mistake, I figured out that if you hide all of the PS Move controllers from ALL of the PS eye cameras, the black screen issue goes away. I have the rumble disabled on the controllers, and using Riftcat+PS move service + PS Move Freepie Bridge.

If you need to see/hear more of my setup, let me know, and I'll be happy to share and test whatever you want.

Hopefully this helps shed some light on why this is happening.

Hello all, this post is in regards to the black screen issue that NeoToriyama was looking into.

Sorry for adding to an older thread, and I'm not entirely sure if this is the correct one to do so, but I found a bit more data on the black screen issue that I have not seen anywhere on any forum.

By mistake, I figured out that if you hide all of the PS Move controllers from ALL of the PS eye cameras, the black screen issue goes away. I have the rumble disabled on the controllers, and using Riftcat+PS move service + PS Move Freepie Bridge.

If you need to see/hear more of my setup, let me know, and I'll be happy to share and test whatever you want.

Hopefully this helps shed some light on why this is happening.

@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Sep 28, 2016

Collaborator

That is super interesting! I would love to hear some more details about your setup:

  • How many cameras do you have?
  • How many controllers do you have hooked up?
  • What is the headset you are using?

Also when the controllers become visible again does the black screen come back right away? Or just some time later?

My current theory is that UDP controller stream stream from PSMoveService to SteamVR is sending too many packets and is overflowing the network stack on the OS. This is interfering with RiftCat's ability to broadcast video to your headset.

One thing we could try as an experiment is lowering the controller update rate. This will lower the number of UDP packets we're sending out to SteamVR. This is configured with the "controller_poll_interval" value in %appdata%\PSMoveService\ControllerManagerConfig.json. The default is current 2ms, which is honestly kind of high. Try changing that to "13" and see of that fixes it for you. Just note that the higher you change that update rate, the less smooth the controller may start to feel.

Ultimately I would like to switch how PSMoveService communicates with SteamVR. Either to using a named pipe or embedding PSMoveService directly into the SteamVR plugin. This would completely eliminate the UDP traffic, but it's going to be a while before I can do that work. So hopefully changing this config value will act as a stop gap.

Collaborator

HipsterSloth commented Sep 28, 2016

That is super interesting! I would love to hear some more details about your setup:

  • How many cameras do you have?
  • How many controllers do you have hooked up?
  • What is the headset you are using?

Also when the controllers become visible again does the black screen come back right away? Or just some time later?

My current theory is that UDP controller stream stream from PSMoveService to SteamVR is sending too many packets and is overflowing the network stack on the OS. This is interfering with RiftCat's ability to broadcast video to your headset.

One thing we could try as an experiment is lowering the controller update rate. This will lower the number of UDP packets we're sending out to SteamVR. This is configured with the "controller_poll_interval" value in %appdata%\PSMoveService\ControllerManagerConfig.json. The default is current 2ms, which is honestly kind of high. Try changing that to "13" and see of that fixes it for you. Just note that the higher you change that update rate, the less smooth the controller may start to feel.

Ultimately I would like to switch how PSMoveService communicates with SteamVR. Either to using a named pipe or embedding PSMoveService directly into the SteamVR plugin. This would completely eliminate the UDP traffic, but it's going to be a while before I can do that work. So hopefully changing this config value will act as a stop gap.

@POEDaley

This comment has been minimized.

Show comment
Hide comment
@POEDaley

POEDaley Sep 28, 2016

I have 4 cameras, and 3 controllers. The cameras are split between USB 2.0 and 3.0 ports to even out the load. I am using the Gear VR with the riftcat gear vr edition software, but I've tested with standard cardboard ones as well in the past.

I have been posting some setup guides that Riftcat has been using, and looking through this stuff should give you a pretty clear idea of how I have everything setup.

https://www.youtube.com/watch?v=W7rogPZFdL4

I have other videos in there as well that may offer some insight as to how I run it.

I will most certainly try that suggestion you had. I will also try to confirm if it's the head tracking controller only that needed to be hidden, or if I need to hide all 3. I know that just hiding the 2 hand controllers didn't fix it.

Also, when it came back, it almost seemed to fade in, but it may have been an illusion since the game put me right at floor level and looking straight down by the way I was holding the controller. I was playing The Last Sniper VR demo, and that game really had a lot of issues with black screen for me.

I will do much more testing later tonight to try to gather as many details as possible that you may want. if you want me to run any more specific tests, just let me know.

Thanks for all your help and great work so far!

I have 4 cameras, and 3 controllers. The cameras are split between USB 2.0 and 3.0 ports to even out the load. I am using the Gear VR with the riftcat gear vr edition software, but I've tested with standard cardboard ones as well in the past.

I have been posting some setup guides that Riftcat has been using, and looking through this stuff should give you a pretty clear idea of how I have everything setup.

https://www.youtube.com/watch?v=W7rogPZFdL4

I have other videos in there as well that may offer some insight as to how I run it.

I will most certainly try that suggestion you had. I will also try to confirm if it's the head tracking controller only that needed to be hidden, or if I need to hide all 3. I know that just hiding the 2 hand controllers didn't fix it.

Also, when it came back, it almost seemed to fade in, but it may have been an illusion since the game put me right at floor level and looking straight down by the way I was holding the controller. I was playing The Last Sniper VR demo, and that game really had a lot of issues with black screen for me.

I will do much more testing later tonight to try to gather as many details as possible that you may want. if you want me to run any more specific tests, just let me know.

Thanks for all your help and great work so far!

@POEDaley

This comment has been minimized.

Show comment
Hide comment
@POEDaley

POEDaley Sep 29, 2016

I tested it again, and found that I only had to "hide" the head tracked controller. As soon as it was hidden, the screen showed up again on the phone. I made sure I kept the 2 hand controllers in plain view of all of the cameras. If I brought the head tracked controller back into view right away, it would black screen soon after again.

As far as trying to change that setting, that file doesn't exist. Everything does work fine though, so it's strange that I don't have it. Below is a list of the entire contents of that folder in appdata that you linked:

image

I tested it again, and found that I only had to "hide" the head tracked controller. As soon as it was hidden, the screen showed up again on the phone. I made sure I kept the 2 hand controllers in plain view of all of the cameras. If I brought the head tracked controller back into view right away, it would black screen soon after again.

As far as trying to change that setting, that file doesn't exist. Everything does work fine though, so it's strange that I don't have it. Below is a list of the entire contents of that folder in appdata that you linked:

image

@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Sep 29, 2016

Collaborator

Ah it looks like ControllerManagerConfig.json only gets saved out when a shutdown signal is received. This only happens in windows when either running PSMoveService from the command line, then sending a Ctrl+C or if an exception occurs.

However, you can also manually create ControllerManagerConfig.json and paste the following in it:

{
    "controller_reconnect_interval": "1000",
    "controller_poll_interval": "13",
    "tracker_reconnect_interval": "10000",
    "tracker_poll_interval": "13"
}
Collaborator

HipsterSloth commented Sep 29, 2016

Ah it looks like ControllerManagerConfig.json only gets saved out when a shutdown signal is received. This only happens in windows when either running PSMoveService from the command line, then sending a Ctrl+C or if an exception occurs.

However, you can also manually create ControllerManagerConfig.json and paste the following in it:

{
    "controller_reconnect_interval": "1000",
    "controller_poll_interval": "13",
    "tracker_reconnect_interval": "10000",
    "tracker_poll_interval": "13"
}
@POEDaley

This comment has been minimized.

Show comment
Hide comment
@POEDaley

POEDaley Sep 29, 2016

Thanks. File is created and here are some testing results:
The Last Sniper VR:
Tracker/Controller set to 13/13 = no more head tracking at all (even in steam VR homescreen)
Tracker/Controller set to 2/2 = working as usual with black screens
Tracker/Controller set to 8/8 = Head tracking working but noticed poorer tracking, black screen showing up just as much, or worse.
Tracker/Controller set to 1/1 = Black screen issue similar to 2/2

Would it be worth while testing different tracker and controller settings? Such as 2/8 or 8/2? Or would that not help? If so, let me know how you would like me to modify

Note 1:
I tried some of the settings with other games, and never ran into issues (Rec Room, Duo). Another interesting tidbit that may be worth noting.... The Last Sniper VR runs in full screen window on my 2nd monitor (1080p), whereas the other 2 games run in small windows on my primary 4k screen. 1/1 seemed to work well and had some great tracking in the smaller window games.

Note 2:
Problem is much more frequent when I'm doing a screen record in the Last Sniper VR Demo.

System specs:
i5 6500
gtx 1080
16GB ddr4

Wish I had some success to report back, but this is what I've experienced.

Thanks. File is created and here are some testing results:
The Last Sniper VR:
Tracker/Controller set to 13/13 = no more head tracking at all (even in steam VR homescreen)
Tracker/Controller set to 2/2 = working as usual with black screens
Tracker/Controller set to 8/8 = Head tracking working but noticed poorer tracking, black screen showing up just as much, or worse.
Tracker/Controller set to 1/1 = Black screen issue similar to 2/2

Would it be worth while testing different tracker and controller settings? Such as 2/8 or 8/2? Or would that not help? If so, let me know how you would like me to modify

Note 1:
I tried some of the settings with other games, and never ran into issues (Rec Room, Duo). Another interesting tidbit that may be worth noting.... The Last Sniper VR runs in full screen window on my 2nd monitor (1080p), whereas the other 2 games run in small windows on my primary 4k screen. 1/1 seemed to work well and had some great tracking in the smaller window games.

Note 2:
Problem is much more frequent when I'm doing a screen record in the Last Sniper VR Demo.

System specs:
i5 6500
gtx 1080
16GB ddr4

Wish I had some success to report back, but this is what I've experienced.

@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Sep 29, 2016

Collaborator

Would it be worth while testing different tracker and controller settings? Such as 2/8 or 8/2? Or would that not help? If so, let me know how you would like me to modify

Nah I think just varying both was enough to prove that is wasn't going to work. The tracker update rate effects how quickly we try and repoll the cameras, but that won't cause the controllers to publish data any faster. Bummer that didn't help.

The Last Sniper VR runs in full screen window on my 2nd monitor (1080p), whereas the other 2 games run in small windows on my primary 4k screen.

So there are two possibilities here. This is still network dependent or this is processor dependent. One other way we could narrow this down is to not run psmoveservice, but instead run test_cameras.exe while rift cat is running. The test camera app only opens the PS3eye camera and displays the video feeds (no networking). Part of the video feed processing is pretty expensive (converting from Bayer color mode to RGB). I'd be curious if you still get the screen blackout in this case. I don't know how hard this will be to test without the PSMoveControllers active though.

EDIT: BTW if this does turn out to be "processor dependent" there are optimizations we can do to improve this situation. Currently no optimization work has been done on PSMoveService so far.

Collaborator

HipsterSloth commented Sep 29, 2016

Would it be worth while testing different tracker and controller settings? Such as 2/8 or 8/2? Or would that not help? If so, let me know how you would like me to modify

Nah I think just varying both was enough to prove that is wasn't going to work. The tracker update rate effects how quickly we try and repoll the cameras, but that won't cause the controllers to publish data any faster. Bummer that didn't help.

The Last Sniper VR runs in full screen window on my 2nd monitor (1080p), whereas the other 2 games run in small windows on my primary 4k screen.

So there are two possibilities here. This is still network dependent or this is processor dependent. One other way we could narrow this down is to not run psmoveservice, but instead run test_cameras.exe while rift cat is running. The test camera app only opens the PS3eye camera and displays the video feeds (no networking). Part of the video feed processing is pretty expensive (converting from Bayer color mode to RGB). I'd be curious if you still get the screen blackout in this case. I don't know how hard this will be to test without the PSMoveControllers active though.

EDIT: BTW if this does turn out to be "processor dependent" there are optimizations we can do to improve this situation. Currently no optimization work has been done on PSMoveService so far.

@POEDaley

This comment has been minimized.

Show comment
Hide comment
@POEDaley

POEDaley Sep 30, 2016

I ran the request test, and it appears to not suffer from the black screen issue. Based on what you have theorized, and looking at the data, it does appear that you may be correct in saying it's a processor dependent issue.

Now I'm running an i5 6500 quad core, so it should have enough horse power. In the videos, I'm running it at stock clocks, and it seemed to amplify the issue significantly. I had much more frequent black screens in more modern games on the stock clock vs my 800mhz overclock setting. I disabled the OC because BLK OC is a bit wonky and causes some booting issues at times.

I uploaded 2 unlisted videos for you with different resource monitors open, and I am pinpointing where I experience the black screens. Lucky's tale started up without video, but I have not run that since I setup the PS move service and I didn't reset my height in steam VR setup so steam thought I was laying on the ground since PC move service/freepie wasn't running.

2 videos:
Black screen issue - https://www.youtube.com/watch?v=AthfLVJz3t0
4x PSeye camera test without PS move service - https://www.youtube.com/watch?v=PKz1RzkzGuA&feature=youtu.be

Again, if you want me to collect any more data, just say the word and I'll run it. I'll be happy to help as much as I can to help solve this issue.

EDIT - The issue still happens without recording, but just takes a bit longer to happen which makes me even more confident it's a CPU issue (still happens at 99%+ CPU usage, PS Move service just takes up much more CPU when not recording)

Thanks,

POEDaley commented Sep 30, 2016

I ran the request test, and it appears to not suffer from the black screen issue. Based on what you have theorized, and looking at the data, it does appear that you may be correct in saying it's a processor dependent issue.

Now I'm running an i5 6500 quad core, so it should have enough horse power. In the videos, I'm running it at stock clocks, and it seemed to amplify the issue significantly. I had much more frequent black screens in more modern games on the stock clock vs my 800mhz overclock setting. I disabled the OC because BLK OC is a bit wonky and causes some booting issues at times.

I uploaded 2 unlisted videos for you with different resource monitors open, and I am pinpointing where I experience the black screens. Lucky's tale started up without video, but I have not run that since I setup the PS move service and I didn't reset my height in steam VR setup so steam thought I was laying on the ground since PC move service/freepie wasn't running.

2 videos:
Black screen issue - https://www.youtube.com/watch?v=AthfLVJz3t0
4x PSeye camera test without PS move service - https://www.youtube.com/watch?v=PKz1RzkzGuA&feature=youtu.be

Again, if you want me to collect any more data, just say the word and I'll run it. I'll be happy to help as much as I can to help solve this issue.

EDIT - The issue still happens without recording, but just takes a bit longer to happen which makes me even more confident it's a CPU issue (still happens at 99%+ CPU usage, PS Move service just takes up much more CPU when not recording)

Thanks,

@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Sep 30, 2016

Collaborator

Thanks a ton for testing that making those videos! Especially with the task manager running. Super interesting. It looks like the PSMoveService is hovering around 30% CPU, which is definitely too much. It looks like the just the test camera feeds were running at 7%. Fortunately there is some low hanging optimization fruit. I just need to define a region of interest around the controller in the video feed, rather than processing the entire video frame. This should help a lot. I'll see what I can do this weekend.

Also worth pointing out the network transmission rates in the task manager. PSMoveService was a tiny blip (<1MB/s) compared to the 22MB/s VRidge was using. So I think this likely isn't a network saturation issue on PSMoveService's part. The other interesting network thing I noticed was that when you hit the black screen the vridge network rate dropped from 22MB/s down to 0.8MB/s:

https://www.youtube.com/watch?v=AthfLVJz3t0&t=2m5s

I don't know if this is because the VRidge is cutting back the video stream rate or if it just started generating black output frames and they are compressing really well.

Might be worth sending these videos over to the VRidge guys to see if they have any thoughts about these videos too.

Collaborator

HipsterSloth commented Sep 30, 2016

Thanks a ton for testing that making those videos! Especially with the task manager running. Super interesting. It looks like the PSMoveService is hovering around 30% CPU, which is definitely too much. It looks like the just the test camera feeds were running at 7%. Fortunately there is some low hanging optimization fruit. I just need to define a region of interest around the controller in the video feed, rather than processing the entire video frame. This should help a lot. I'll see what I can do this weekend.

Also worth pointing out the network transmission rates in the task manager. PSMoveService was a tiny blip (<1MB/s) compared to the 22MB/s VRidge was using. So I think this likely isn't a network saturation issue on PSMoveService's part. The other interesting network thing I noticed was that when you hit the black screen the vridge network rate dropped from 22MB/s down to 0.8MB/s:

https://www.youtube.com/watch?v=AthfLVJz3t0&t=2m5s

I don't know if this is because the VRidge is cutting back the video stream rate or if it just started generating black output frames and they are compressing really well.

Might be worth sending these videos over to the VRidge guys to see if they have any thoughts about these videos too.

@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Sep 30, 2016

Collaborator

Oh also, I noticed you commented about the controller you were using for hour head showing up as your hand in the first video. Did you know about the HMD controller filter feature that just got added in the latest (5.1) release:

https://github.com/cboulay/PSMoveService/wiki/Steam-VR-Setup#hmd-controller-3rd-controller-filtering

It let's you hide a controller from SteamVR so that games won't try and use it as a hand. FreePIE will still see all 3 controllers (since this is just a steamvr plugin setting).

Collaborator

HipsterSloth commented Sep 30, 2016

Oh also, I noticed you commented about the controller you were using for hour head showing up as your hand in the first video. Did you know about the HMD controller filter feature that just got added in the latest (5.1) release:

https://github.com/cboulay/PSMoveService/wiki/Steam-VR-Setup#hmd-controller-3rd-controller-filtering

It let's you hide a controller from SteamVR so that games won't try and use it as a hand. FreePIE will still see all 3 controllers (since this is just a steamvr plugin setting).

@POEDaley

This comment has been minimized.

Show comment
Hide comment
@POEDaley

POEDaley Sep 30, 2016

I didn't know about that release. I'll be sure to try it out this weekend. Thanks for that!

In regards to CPU usage, I took another screenshot this morning before work to try out one more thing to help possibly narrow down the issue. I ran PS Move Service with RiftCat but I did NOT connect any of the controllers. The result is similar.

As I mentioned, when I wasn't screen recording, PS Move Service would consume just above 50%. So it appears the camera tracking and controllers seem to consume a fair amount each. I'll double check that tonight and return to you if it's any different.

Screenshot:
untitled

I didn't know about that release. I'll be sure to try it out this weekend. Thanks for that!

In regards to CPU usage, I took another screenshot this morning before work to try out one more thing to help possibly narrow down the issue. I ran PS Move Service with RiftCat but I did NOT connect any of the controllers. The result is similar.

As I mentioned, when I wasn't screen recording, PS Move Service would consume just above 50%. So it appears the camera tracking and controllers seem to consume a fair amount each. I'll double check that tonight and return to you if it's any different.

Screenshot:
untitled

@balukin

This comment has been minimized.

Show comment
Hide comment
@balukin

balukin Sep 30, 2016

Also worth pointing out the network transmission rates in the task manager. PSMoveService was a tiny blip (<1MB/s) compared to the 22MB/s VRidge was using. So I think this likely isn't a network saturation issue on PSMoveService's part. The other interesting network thing I noticed was that when you hit the black screen the vridge network rate dropped from 22MB/s down to 0.8MB/s:

I don't know if this is because the VRidge is cutting back the video stream rate or if it just started generating black output frames and they are compressing really well.

(Note: I'm one of vridge devs) Vridge is using H264 which compresses static sequences pretty well so <1Mbps is expected in black screen scenario. Network saturation impact can be tested by reducing VRidge's bitrate in desktop settings to 1 Mbps to exclude high network usage as a cause of the problem.


I'd like to add a fact that vridge users reported the same problem with Leap Motion's SteamVR driver (non-official, based on Hydra driver) so it may be bugged interaction between vridge and SteamVR or SteamVR and third party controllers. We tried to reproduce it with Leap but unfortunately it was working well without blackouts for hours. Vive wands were working alright with vridge as well. We need to get new USB BT adapter to test it with PS Move Service because it's the most common controller used with vridge.

While we can't reproduce it at this moment we could use SteamVR log file with black screen's timestamp. We received some SteamVR logs already but it's hard to tell when it went black so please note when black screen happens and include this timestamp in your comment. Files can be found in Steam\logs directory. vrserver.txt is the most important one but attach vrcompositor and vrmonitor too.

balukin commented Sep 30, 2016

Also worth pointing out the network transmission rates in the task manager. PSMoveService was a tiny blip (<1MB/s) compared to the 22MB/s VRidge was using. So I think this likely isn't a network saturation issue on PSMoveService's part. The other interesting network thing I noticed was that when you hit the black screen the vridge network rate dropped from 22MB/s down to 0.8MB/s:

I don't know if this is because the VRidge is cutting back the video stream rate or if it just started generating black output frames and they are compressing really well.

(Note: I'm one of vridge devs) Vridge is using H264 which compresses static sequences pretty well so <1Mbps is expected in black screen scenario. Network saturation impact can be tested by reducing VRidge's bitrate in desktop settings to 1 Mbps to exclude high network usage as a cause of the problem.


I'd like to add a fact that vridge users reported the same problem with Leap Motion's SteamVR driver (non-official, based on Hydra driver) so it may be bugged interaction between vridge and SteamVR or SteamVR and third party controllers. We tried to reproduce it with Leap but unfortunately it was working well without blackouts for hours. Vive wands were working alright with vridge as well. We need to get new USB BT adapter to test it with PS Move Service because it's the most common controller used with vridge.

While we can't reproduce it at this moment we could use SteamVR log file with black screen's timestamp. We received some SteamVR logs already but it's hard to tell when it went black so please note when black screen happens and include this timestamp in your comment. Files can be found in Steam\logs directory. vrserver.txt is the most important one but attach vrcompositor and vrmonitor too.

@zelmon64

This comment has been minimized.

Show comment
Hide comment
@zelmon64

zelmon64 Sep 30, 2016

Contributor

@balukin I got a black screen so I sent the logs from the app along with the time (21:05) and a brief description. Here are all the other logs (as well as the ones from the app - hard to find).
160930-2105-logs.zip
Should I also send this to your team directly?

Contributor

zelmon64 commented Sep 30, 2016

@balukin I got a black screen so I sent the logs from the app along with the time (21:05) and a brief description. Here are all the other logs (as well as the ones from the app - hard to find).
160930-2105-logs.zip
Should I also send this to your team directly?

@POEDaley

This comment has been minimized.

Show comment
Hide comment
@POEDaley

POEDaley Sep 30, 2016

Here are my logs.
Steam VR Logs.zip

The black screen issue happened right at 22:00.

Here are my logs.
Steam VR Logs.zip

The black screen issue happened right at 22:00.

@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Oct 3, 2016

Collaborator

For anyone wanting to do a quick test, the Alpha 5.2 build I just uploaded has a small perf optimization that should reduce the CPU load of PSMove service a bit (about 5% on my two camera setup). I added a lookup table for converting from RGB to HSV color spaces. This was (suprisingly) one of the larger perf hotspots and one of the simplest to address (had the fewest testing implications). I'm particularly curious to see how much it helps 3 or 4 camera setups.

https://github.com/cboulay/PSMoveService/releases/tag/v0.9-alpha5.2

Collaborator

HipsterSloth commented Oct 3, 2016

For anyone wanting to do a quick test, the Alpha 5.2 build I just uploaded has a small perf optimization that should reduce the CPU load of PSMove service a bit (about 5% on my two camera setup). I added a lookup table for converting from RGB to HSV color spaces. This was (suprisingly) one of the larger perf hotspots and one of the simplest to address (had the fewest testing implications). I'm particularly curious to see how much it helps 3 or 4 camera setups.

https://github.com/cboulay/PSMoveService/releases/tag/v0.9-alpha5.2

@POEDaley

This comment has been minimized.

Show comment
Hide comment
@POEDaley

POEDaley Oct 4, 2016

I tested it with my 4 camera setup, and can confirm it gave me anywhere from a 5-10% CPU reduction. 5.1 would range from 55-65%, and 5.2 would range from 50-57. I would indeed call this a success. I still ran into the black screen while mucking about in the lab, but it took longer to get there.

Interesting note - My ram usage seemed to have nearly doubled. This is a non issue though since ram is a much easier issue to out muscle. I would much rather this be memory hungry than CPU hungry. Edit - this is more of an observation other than a complaint.

5.1:
early

5.2:
later

POEDaley commented Oct 4, 2016

I tested it with my 4 camera setup, and can confirm it gave me anywhere from a 5-10% CPU reduction. 5.1 would range from 55-65%, and 5.2 would range from 50-57. I would indeed call this a success. I still ran into the black screen while mucking about in the lab, but it took longer to get there.

Interesting note - My ram usage seemed to have nearly doubled. This is a non issue though since ram is a much easier issue to out muscle. I would much rather this be memory hungry than CPU hungry. Edit - this is more of an observation other than a complaint.

5.1:
early

5.2:
later

@lonqq

This comment has been minimized.

Show comment
Hide comment
@lonqq

lonqq Oct 11, 2016

Hello,
I'm Vridge developer as well and I was investigating black screen issue for the last few days. I've found out that problem always appears in parallel to the following line in the vrserver log:

Tue Oct 11 2016 15:24:34.869 - Unknown message type Unknown VRMsgType (1049096) (1325400064 byte payload) from TheLab (19556). Disconnecting.

After that screen goes black and does not come back until application is closed. This line clearly indicates that application is disconnecting from vrserver. Because of that, it is no longer submiting new frames and screen stays black. I belive that it does not come back to rendering SteamVR home screen because scene switching mechanism is based on process status, not IPC connection status. In the log it looks like this:

Tue Oct 11 2016 15:27:03.662 - Setting pidSceneFocus to 0 because process 19556 isn't running anymore

Problematic line pretty clearly indicates that data in the IPC stream was malformed, which is a source of disconnection. Reason of that is not known to me, because it is internal error of SteamVR server. I think that this might be synchronization problem when two or more drivers are sending data, but I can only guess.
I've tested it with both Vridge and Oculus DK2, both of HMDs are affected by this issue, so probably we will not be able to fix it on our side. I've also checked how CPU usage is affecting a speed of bug occurrence, but for me it seems to be not correlated. Even with high CPU usage, with Prime95 running in background, issue appeared after similar amount of time.
Thanks for all your logs, they were really helpful.

lonqq commented Oct 11, 2016

Hello,
I'm Vridge developer as well and I was investigating black screen issue for the last few days. I've found out that problem always appears in parallel to the following line in the vrserver log:

Tue Oct 11 2016 15:24:34.869 - Unknown message type Unknown VRMsgType (1049096) (1325400064 byte payload) from TheLab (19556). Disconnecting.

After that screen goes black and does not come back until application is closed. This line clearly indicates that application is disconnecting from vrserver. Because of that, it is no longer submiting new frames and screen stays black. I belive that it does not come back to rendering SteamVR home screen because scene switching mechanism is based on process status, not IPC connection status. In the log it looks like this:

Tue Oct 11 2016 15:27:03.662 - Setting pidSceneFocus to 0 because process 19556 isn't running anymore

Problematic line pretty clearly indicates that data in the IPC stream was malformed, which is a source of disconnection. Reason of that is not known to me, because it is internal error of SteamVR server. I think that this might be synchronization problem when two or more drivers are sending data, but I can only guess.
I've tested it with both Vridge and Oculus DK2, both of HMDs are affected by this issue, so probably we will not be able to fix it on our side. I've also checked how CPU usage is affecting a speed of bug occurrence, but for me it seems to be not correlated. Even with high CPU usage, with Prime95 running in background, issue appeared after similar amount of time.
Thanks for all your logs, they were really helpful.

@HipsterSloth

This comment has been minimized.

Show comment
Hide comment
@HipsterSloth

HipsterSloth Oct 11, 2016

Collaborator

@lonqq Thanks for digging into that! I think the theory about this being a synchronization issue between multiple drivers makes the most sense. A while ago a dev at Valve was helping me debug a crash with an early version of my psmove plugin he had mentioned that each plugin runs in it's own thread. I could totally believe in a situation where there are multiple driver threads running some message queue gets corrupted due some improper state synchronization.

Did you guys want to reach out to Valve about this or would you like me to? I know one of the devs on the SteamVR team I can ask about this. I'm also going to Steam Dev Days and could ask one of the devs about it there too.

Collaborator

HipsterSloth commented Oct 11, 2016

@lonqq Thanks for digging into that! I think the theory about this being a synchronization issue between multiple drivers makes the most sense. A while ago a dev at Valve was helping me debug a crash with an early version of my psmove plugin he had mentioned that each plugin runs in it's own thread. I could totally believe in a situation where there are multiple driver threads running some message queue gets corrupted due some improper state synchronization.

Did you guys want to reach out to Valve about this or would you like me to? I know one of the devs on the SteamVR team I can ask about this. I'm also going to Steam Dev Days and could ask one of the devs about it there too.

@gb2111

This comment has been minimized.

Show comment
Hide comment
@gb2111

gb2111 Oct 12, 2016

Contributor

@HipsterSloth,
It would be great if you can talk to guys.
Yesterday I noted that when I go to menu and back the game is also back from black screen. But it does not work in all cases.
I think I also notes this happens on non-steam game.

Contributor

gb2111 commented Oct 12, 2016

@HipsterSloth,
It would be great if you can talk to guys.
Yesterday I noted that when I go to menu and back the game is also back from black screen. But it does not work in all cases.
I think I also notes this happens on non-steam game.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment