OpenTPCast rumble only on one controller

Submitted by rdpeake on #1

I'm using an OpenTPCast to connect an oculus rift to a windows 10 PC. I'm asking this here rather than the tpcast discord as i think this is a virtual here issue?

The base TPCast runs with linux kernel version 4.9, but i have updated that to use 4.14 hoping that may result in better experience. I eventually found that upping the servers CompressionLimit to 800, up from the base 384 resulted in better tracking and somewhat better rumble response.

My issue is though, i am only ever able to get rumble from 1 touch controller at a time (at least in the game beat saber) when wired i can get both to function as expected. with a mod (which seems to be the solution many have found in the opentpcast forum) i can get a somewhat better experience, but that is simply because the the mod sends more vibrations allowing the 2 touch controllers to vibrate more interleaved.

Is this likely to be an issue with virtual here, or a limitation of the tpcast hardware (which is basically a raspberry pi 3, with usb 5ghz wifi) and is there anything i can do to help work out where the issue may lie?

Submitted by Michael on Mon, 2019/03/18 - 13:59

#2

USB devices are specified in a series of descriptors which are contained in the hardware of the usb device. It knows certain specific requests when it powers up to tell the operating system about the type of device it is. The descriptors in order of generality are Device->Configuration (can be multiple)->Interface (usually multiple)->Endpoints (usually multiple) . So the endpoints are qualified depending on the configuration number selected and possibly the set alternate interface requests previously sent to the device. That is the numbers you are seeing separated by dots. Usually endpoint 0 means a control endpoint which is always there and endpoints are numbered 1,2,3 etc with a direction as the first bit like 81,82 etc. This website is very good at explaining endpoints https://www.beyondlogic.org/usbnutshell/usb4.shtml and this is good at explaining descriptors which describe the device and its endpoints https://www.beyondlogic.org/usbnutshell/usb5.shtml#DeviceDescriptors

Submitted by rdpeake on Mon, 2019/03/18 - 14:09

#3

So the fact that it changes to a control endpoint in both cases when the failure case occurs isn't necessarily an issue with virtual here not sending something on to the end device but an error could be elsewhere (if there is indeed an error and not protocol differences)? or are control messages handle differently than the other end points?

Submitted by Michael on Mon, 2019/03/18 - 14:20

#5

Control endpoints are special. They never jam but sometimes non-control endpoints jam. So these need to be cleared with a CLEAR_FEATURE HALT https://www.beyondlogic.org/usbnutshell/usb6.shtml#StandardEndpointRequ… sent to the control endpoint, thats probably what it is doing. The endpoint has some error condition that needs to be cleared to continue.

You could use something like usblyzer i think that has a free trial and its better at showing usb messages

Submitted by rdpeake on Mon, 2019/03/18 - 14:30

#6

Most of the x.x.0 request - when i looked at the details at the bottom where set feature requests - but i do note that they take longer to get responses on tpcast than they do in direct connections which could be the issues - as you hint at when you mentioned protocol issues. (i realise the delay is likely just notwork comms and probably not a bug)

I shall try usblyzer and see what i can get.

Submitted by rdpeake on Mon, 2019/03/18 - 19:49

#7

So i've run a usblyzer test for direct and tpcast:
direct: https://www.dropbox.com/s/qj2to0e3o65vw43/direct.ulz?dl=0
tpcast: https://www.dropbox.com/s/6s1mxzi9g1jqblv/tpcast.ulz?dl=0

The only errors that show up are associated with a service running on the pc trying to do something with the usdhid device - however it happens infrequently enough that i don't suspect that this is the cause. if you've got any tips on what to be looking for - as everything i'm seeing seems to indicate that it should be working - unless your suspicion that there is some form of time gate involved.

I notive in the oculus log output that there are warnings saying 'hid get parent failed: 13' only when the tpcast is involved - but i don't know enough about this to work out just what is causing the communications to fail - without errors on the usb protocol side of things.

Submitted by Michael on Mon, 2019/03/18 - 20:59

#8

Thanks for the usblyzer logs. Yes they look fine, no error in either case so all commands are send/received correctly

The "parent hid error" is interesting,

can you plug everything directly into the pc then bring up device manager then select "View->By Container" and then see if all the oculus devices plugged in are under one particular container.

Then repeat the process when connected via virtualhere.

Do they look identical. Are the branches/leaves identical?

Submitted by Michael on Tue, 2019/03/19 - 09:09

#10

OK that could be a clue to the issue. Can you stop the virtualhere server on the tpcast (or your test server) then add the line in the config.ini file

CoalesceCompanionHub=true

then restart the server. Now try to use the oculus devices. Do they work ok now? Do they all appear under the same branch when used via virtualhere just like when plugged in directly?

Submitted by rdpeake on Tue, 2019/03/19 - 18:55

#11

Hey Michael - i am assuming i've done it correctly (copied your line directly just to be safe) and restarted tpcast as well to make double sure.

The setting did not change anything though - shows up as 2 different containers and has the same issue when playing.

Copy of the config (it is the same file for oculus and vive):

ServerName=TPCast
onDeviceIgnore=return 0
onChangeNickname=return 1
onReset.0bb4.2c87=
onReset.28de.2000=
DeviceNicknames=Vive Camera,0bb4,2c87,1122
IgnoredDevices=424/ec00,bda/8194,bda/811
License=####
It=1549367294
CompressionLimit=800
onReset.2833.0031=
onReset.2833.0330=
CoalesceCompanionHub=true

2833.0031 is the 'rift' device and 2833.0330 is the 'rift audio' device (this would be why adding resets before did very little - hind sight)

I want to note that it is possible that the audio device can fail to disconnect properly which ends up requiring a pc reboot to fix - but i don't want to distract from the main purpose here - the vibration.

Submitted by rdpeake on Tue, 2019/03/19 - 19:00

#12

actually - those last 2 onReset were persistances of what i added before when you asked me to - and why i didn't notice a difference when i 'removed them' in the client - so ignore that side of things

Submitted by Michael on Tue, 2019/03/19 - 20:01

#13

Actually sorry it is

CoalesceCompanionHub=1

Submitted by rdpeake on Tue, 2019/03/19 - 22:03

#14

Ok - with that setting, everything that the tpcast is forwarding does show up under 1 container - and it does feel smoother - but it does miss the dual vibration at once. The only thing that i can see which differs between the 2 containers - is the direct connection include a generic usb hub, and generic super speed hub (if connected under usb 3.0) which is not present on virtual here's device forward. i do note that none of the other containers include the hubs even when they obviously have one in them (like keyboards or disk readers with their own usb ports).

Submitted by rdpeake on Tue, 2019/03/19 - 23:18

#15

I also note i still see GM_Get_Parent failed: 13 in the log file along with these usb failures: https://pastebin.com/7Vy12w3Z

i also see this in the log: if it means anything - 19/03 19:11:37.051 {WARNING} [TouchHaptics] RightTouch: Outstanding constant vibration request failed: {'ErrorCode':'RequestFailed','Report':26,'OSErrorCode':2,'ErrorDetail':'AsyncSetReport.AsyncWirelessWrite.writeBlocking.waitForBusyClearBlocking.GetReport.GetFeature.DeviceIoControlFail'}

Submitted by Michael on Wed, 2019/03/20 - 09:31

#16

OK so the coalesce changes is working as it should and all devicesappear under the same Container. So it seems like the haptic devices were getting detected ok anyway before the coalesce change, i dont know what is causing that error you post. This is probably the main issue all along. Since you dont have the source to the driver or that code we are back to square one :)

Submitted by rdpeake on Wed, 2019/03/20 - 18:38

#17

I know i'm harping on about the usb hubs again... but does the fact that the hubs are in the container when directly wired mean anything - the concept of a container is new to me and not sure what the significance is (if any) that the hubs are present in the rift, but not in any other container.

Submitted by Michael on Wed, 2019/03/20 - 18:53

#18

The hubs in the container arent important, the container is used so the devices can find each other because they all have the same container id. I thought with the previous error you mentioned, the driver couldnt find the attached trigger HID device so thats why i have that special setting to make sure the container id is passed through from the real device attached to the virtualhere server. The hubs arent important because virtualhere coalesces the hubs into one and presents that container id to the operating system so it can place the devices correctly in the tree.

Submitted by rdpeake on Wed, 2019/03/20 - 19:52

#19

Yeah - i just find it weird that individually the vibration works perfectly fine - but the moment both devices need to vibrate it falls apart - should probably try using a pi 3 b - with a lan cable to see if it is latency - as i would assume lan latency would be significantly less than the wifi. it does all feel smoother with the coalesce setting - but that could be a placebo.

Submitted by rdpeake on Tue, 2019/03/26 - 22:57

#20

having finally been able to reproduce the issue in isolation (thanks to the haptics code from beat saber) i was able to get the tpcast to work reliably by doubling the length of haptics patterns being sent to the touch controllers (regardless of the pattern being used, just send it twice in a row and it works fine). Does this raise any ideas about what could cause the issue in tpcast (if it is in tpcast) or the underlying oculus libraries?

Submitted by Michael on Wed, 2019/03/27 - 09:16

#21

OK thats great that you can isolate the issue, my suggestions is to try sending oculus that bug report and see if you get a response

Submitted by rck on Sat, 2019/08/17 - 08:18

#22

Hello rdpeake & Michael,

I'm a new user of tpcast & virtualhere, and I got the exact same problem than you with beatsaber :)
I find this thread after testing RumbleEnhancerOculus as workaround, and I read the whole 71 posts about your quest !
It was one very interesting reading, full of good ideas, good suggestions, and good tries to fix this problem !

@rdpeake, since your last post was 5 months ago, did you got anything new about the problem ?
Maybe another build of linux with usb3, or a response from oculus to help us ? (let's dream)
I'm sure if beatsaber generate this usb problem, other games can have the same one, a global solution would be perfect for sure :)

ps: Can you also explain me how did you send twice the haptic paterns ?

Submitted by rdpeake on Sat, 2019/08/17 - 23:35

#23

Hey,

So i've not played beat saber for a while due to health reasons - so not looked into this too much. However i did report the issue with TPCast to Split from beat saber dev team. The issue is in the Oculus unity library to do with haptic clips. I haven't actually reported the issue to oculus dev team - because i was hoping split was going to do something about it - but never followed that up.
The way the oculus hardware is connected - the pc software uses the presence of a usb 3.0 hub to show that you have connected it by usb 3.0 - but all the devices run on 1.1 speeds via the 2.0 hub - so the faster SoC may have reduced what ever the issue is with the oculus library - but again, not played around with this too much.

I was using the RumbleEnhancerOculus mod for beat saber - and part of that mod adds a rumble pattern to an ini file that defines it's custom rumble patterns - i just copied and pasted the pattern after it - so the pattern was twice as long, and that seemed to resolve the issue for me reliably. I don't know if this mod has been updated since though.

Submitted by rck on Fri, 2019/08/23 - 01:35

#24

RumbleEnhancerOculus last version is from last april 2019, but it's still working fine with the latest beatsaber release (1.2.0), so for the moment this workarround is ok for me.
Thanks about reporting the issue with TPCast team, let's hope they will speak with beatsaber dev.
About "faster SoC", I forget what are you refering about, a virtualhere settings ?
If so, do you know where I can try it with OpenTPCast ?

Cheers