Wireless usb 3 bridge for oculus link, is it possible?

Submitted by kgian on #1

With the release of oculus link you can use the quest vr HMD as a pc headset, connected with just a single usb 3 cable. I was thinking if it can be done wirelessly by setting up a usb 3 wireless bridge with VH.

The requirements of Oculus link is 150mbps usb transfer speed.
1) Can it be done by using a RPi 4 as a server with a good AC 5GHz router?
2) Does the computer see the connected device as a device connected to a usb port?
3) Will it work with the generic Virtualhere RPi4 build, at least for the testing? What would be the benefit of the specialised version?

Thanks!

Submitted by Michael on Wed, 2019/11/20 - 02:50

#2

Im not sure, i think that it would probably need a low latency link and using virtualhere over wifi with the chip in the pi4 (which is not very good) probably wont work. You can still test it with the normal pi4 build in trial mode. The optimized pi4 build would reduce the cpu usage for similar or greater performance.

Im pretty sure virtualhere server android App can actually can run inside the quest as i have customers who do that. But im not sure why they do that...

Submitted by schoenwaldnils on Sun, 2019/11/24 - 04:08

#3

Hi there,

I just did that. Used RPi4, 5GHz router. Technically it does work. But the latency is pretty bad.
Sadly with and without the specialised version.

@Michael is there a way to setup virtualhere inside the quest using adb?
If yes, is it possible with the trial version?
I just purchased the full version the test the RPi4.
I would not like to purchase the android version too, only to see that it doesn't work either :/

Submitted by mrchriz on Mon, 2019/11/25 - 20:00

#4

Hi,

I'm trying to repurpose the TPCast hardware (using OpenTPCast and virtualhere) for Oculus Quest with Link over wifi.

I can connect the TPCast power box (raspi based) to Oculus Quest and vhui on win 10 shows the Quest usb port (file transfer/adb is possible).

The TPCast hardware apparently only supports usb 2. Hence the Oculus software on win 10 complains that the connection to link is not using usb 3.

Is there a way to present/emulate a virtualhere client port to win 10 as usb 3 although the server port is only usb 2?

Thanks!

Submitted by Michael on Mon, 2019/11/25 - 21:50

#5

@schoenwaldnils yes i think you side load it, download https://www.virtualhere.com/sites/default/files/usbserver/AndroidServer… and try to side load that. See if it works when you side load it first then email me to move the license key.

@mrchriz no its not possible because the electrical parts are different between usb 2 and 3 and its not possible to simulate usb 3 on a usb 2 port.

Submitted by steve1977 on Mon, 2019/11/25 - 22:33

#6

This would be amazing. Help me understand though how this could work with sideloading a VHserver on the Quest? Wouldn't this require a VHclient on the Quest instead? If this works, I'll place an order for the Quest and an Android license immediately.

Submitted by Michael on Tue, 2019/11/26 - 06:28

#7

This is an email i got from a customer on 27th Oct :

"Me too, don't know why it's not working anymore :/
But I've tried it on my Oculus Quest and it works !!! Really impressed.
So, if you can just change my licence to <redacted> that would be awesome.
Thanks for your reactivity !"

I will email him and ask him how he did it

Submitted by schoenwaldnils on Tue, 2019/11/26 - 07:52

#8

@michael I already sideloaded it, But I don't know how I initialize it since I can't open it in the quest like on a normal phone.
Also if this works I'd like to change my order from the raspberry pi to the android version ^^

Submitted by Michael on Tue, 2019/11/26 - 07:58

#9

Sure, ill wait until he responds with info and i can move your license to android

Submitted by kashinoda on Tue, 2019/11/26 - 10:49

#10

If you want to go Wireless would you not be better off with AVLR (free/open source) or VirtualDesktop (paid)? Albeit I imagine the tracking is better using the Link. By the way the bandwidth is actually 150Mbs rather than 150MBs so your main issue is going to be latency.

I'm keen to try out VirtualHere using a 1gig wired connection with the Link. (Bedroom > Living room, Windows client and server). What would the inherent latency be using this setup?

Submitted by kashinoda on Tue, 2019/11/26 - 10:53

#11

<p>Sorry OP you never claimed it was 150MBs, not sure where I got that from!</p>

Submitted by schoenwaldnils on Wed, 2019/12/04 - 04:19

#12

Anything new on this topic?

Submitted by rdpeake on Mon, 2020/05/18 - 20:56

#13

So oculus recently changed the support to usb 2.0 and i have reused the tpcast hardware - as well as an orange pi lite 2 running armbian 5.4 kernal, in trial mode to attempt to connect the quest. couldn't really spot a difference between the 2.
The oculus software doesn't seem to recognise the quest when connected wirelessly in order to enable the service, but i was able to manipulate it via plugging it in directly, and then swapping to the wireless option once the oculus software detects it.

However, once i was able to get it to stream, it was almost working well. there was lag bad enough to not be able to use it in audio and video, but i wasn't sure if this was a hardware issue or wireless bandwidth issue.

Running top on the orange pi, it showed as using 14% cpu, and checking the network bandwidth it was about 12mbps down and 2mbps up (on the host connected to a 5ghz router)

Michael, any suggestions on ways to get more out of the current hardware, or is this just too much overhead that could be optimized away? i can understand it not being possible to get it to work, but was wondering if there were any optimizations i could try to push it as close as i could?

Submitted by Michael on Mon, 2020/05/18 - 22:46

#14

So the oculus is plugged directly into the orangepi usb 2 port and you are using the on-board wifi on the orange pi2 back to a router and the pc? Im not entirely sure how you've plugged it all in. I dont have any of these devices so its a bit confusing for me

Submitted by rdpeake on Tue, 2020/05/19 - 16:46

#15

Hi Michael,

You are correct.

Initially the oculus is plugged into a host pc's usb 2.0 port until it is recognised by the oculus runtime (otherwise it is not detected correctly for the link system)
However after that:
The host pc is connected via a lan cable to the tpcast router (not 100% sure on the specs here, but uses the 5ghz band)
The oculus quest is connected to the Orange Pi Lite 2's usb 2.0 port and uses the orange pi lite 2's built in wifi chip (5ghz capable) (i think this is sdio connection)

I have also used the TPcast as an alternative to the orange pi, though i think the specs are lower on the raspberry pi 3 b clone board inside
This connects the oculus to a usb hub and then to the main chip. also on that hub is a usb wifi chip - the rtl8192du or rtl8812au (depending on version)

Apologies on the lack of details. more than happy to give more, or seek extra details as required.

Submitted by Michael on Tue, 2020/05/19 - 19:44

#16

The cpu is not too loaded so i suspect its the 1T1R wifi chip they are using. The wifi is probably where most of the latency is and i suspect that the video is the main issue.

What is the video? Is there a camera in the quest so you can see the room outside where you are standing? Or is the video the feed from the two eye pieces you look into? Because i remember from the tpcast that the video wont work well if everything else is being used because the video just takes too much bandwidth. The HTC vive video was a camera attached to the lens looking forward in the room to see where you are in the real-world. Just try using everything except the video camera

Submitted by rdpeake on Tue, 2020/05/19 - 20:03

#17

Oculus quest can be used as a pc connected headset - so the video i am referring to is the video + sound feed from the PC to the headset - i just double checked and the wifi speed was the other way from the host (12mbps up, and 2 down from the pc)

I'm fairly sure there is a possibility that it is a bandwidth limitation - i just wanted to see how to 'squeeze' it as much as possible to see if it could be gotten around, or if it is just too much for the wifi/cpu coms with the wifi chip.

In this case - there is only 1 device connected via virtual here - and it is getting a video/sound feed from the host pc and receiving positional data from the headset.

Submitted by rdpeake on Tue, 2020/05/19 - 21:59

#18

I just had a look and any of the settings i can find on the oculus side of things to change video resolution and quality don't change the video being sent to the quest as far as bandwidth. i set it to downsample to 0.1 pixels per pixel and it was still sending 10mbps or more to the quest. the good news is the quests upload (positional tracking) is coming through very quickly just the video is too slow to respond in a timely fashion.

Submitted by Michael on Wed, 2020/05/20 - 08:22

#19

Can you just plug the orangepi directly into an enternet cable instead. That will then remove the wifi component and give you an idea of the real-performance without the wifi bottleneck. That might then point to whether it is cpu bound or not. Although 14% is not too bad already. If it works well directly plugged in then i would suggest perhaps getting a better wifi dongle e.g 2T2R ac dongle (that is supported by linux, eg RTL8812AU or even better the 14 if they make a dongle for that) instead of the on-board orange pi one.

Submitted by rdpeake on Wed, 2020/05/20 - 14:35

#20

I will get a usb to lan dongle and test how that works as it doesn't have on board ethernet and see how that works out.

Submitted by rdpeake on Thu, 2020/05/21 - 18:20

#21

well, that may answer that question. i opted to use a pi 4 i had on hand (as it had a lan port already) and once i got it running i had fairly smooth video (maybe some lag) but audio stutter. But the key thing i observed was the network bandwidth was 50mbps to the quest, and <4mbps from the quest (was also connected to internet network so can't be certain on the quest to pc rate).

I'm guessing this means the oculus software is picking the best speed it can for the connection making me assume the issue is probably wifi speed, given the pi 4 was able to handle the much higher bandwidth in this configuration. or do you think it is worth connecting a lan adapter to the orange pi and testing there?

Submitted by rdpeake on Thu, 2020/05/21 - 18:21

#22

i was connected via usb 2.0 on the pi 4

Submitted by Michael on Thu, 2020/05/21 - 18:38

#23

I think the pi4 will provide optimal performance dont bother with the orangepi
Could you try this

1. Download the latest virtualhere client (exit the current one if it is already running) 5.0.3
2. Edit the file c:\users\yourusername\AppData\Roaming\vhui.ini
add the line under [General]

OptimizeIsoOut=1

3. Save the vhui.ini file then start the client and try the audio/video again.

Does that make a difference? It might not but its worth a try.

Submitted by rdpeake on Thu, 2020/05/21 - 20:05

#24

That didn't seem to produce a noticable difference (maybe slightly smoother on video). the audio seems to 'break up' may be a bandwidth issue on the pi's end given when i was using the orangepi audio was significantly delayed vs what i was hearing on the desktop speakers.

not that it looks like it will matter - and idea why i might need to hot swap the usb between the host and the server for it to be recognised (i'm assuming it's something non standard oculus is doing, but worth asking)

Submitted by Michael on Thu, 2020/05/21 - 20:08

#25

No im not sure why you need to hotswap

Submitted by Bikkies on Sat, 2020/05/23 - 13:39

#26

I've been trying to get a Pi 4 working with this, but can't seem to get the Oculus app to recognise it. The Quest shows up fine in the virtualhere client and I can use it and it looks like it's connected all good, but Link won't activate. Works fine plugging it directly into the PC. I'm assuming I have to do the hot swap process to get it up and running, how would I do this though? I can't just quickly unplug it from the PC and into the Pi. It auto uses it pretty fast but it pops out of the Oculus software before that.

Submitted by Michael on Sat, 2020/05/23 - 17:54

#27

In the virtualhere client right click on the quest and select Custom Event Handler... and paste this line in exactly as shown below:

onReset.$VENDOR_ID$.$PRODUCT_ID$=

Then press OK. Unplug/replug the quest and try using it via virtualhere. Does it work ok now?

Submitted by Bikkies on Sat, 2020/05/23 - 19:39

#28

Nope that didn't seem to help. I can still access it fine through sidequest and file explorer, but the Oculus software only wants to detect it when it's plugged in directly.

Submitted by Bikkies on Sat, 2020/05/23 - 19:40

#29

Actually wait no, scratch that! Spoke too soon. It totally worked after a couple of plug unplug cycles.

Submitted by rdpeake on Sun, 2020/05/24 - 15:05

#30

the reset even didn't seem to resolve the issue for me, but i feel it's going to be a uphill battle to even get it to work. with a LAN connection (and about 50mbps sending) audio seems to stutter on occasion and video has occasional lag. however going via wifi on pi4, or orange pi lite 2 (and about 12mbps) video lag is quite bad, and audio is delayed and stuttering. given there is statements online about oculus using 150mbps usb2.0 bandwidth and i don't think embedded devices have the bus speed? for any wifi device - not sure this will be possible?

Submitted by Michael on Sun, 2020/05/24 - 16:52

#31

The TPCast used 60Ghz ASIC to transmit the video (lattice semi wireless HDMI chip), and the HTC vive wireless (the adapter that came out last year) uses usb over ip but they encode the HDMI video using displaylink ASIC then send it and keep track of the wireless latency.

I suppose once 802.11ax 4x4 or something like that is more ubiquitous it will be possible with plain wifi otherwise you need 60Ghz.

Submitted by rdpeake on Sun, 2020/05/24 - 22:48

#32

with the right amount of bandwidth quest should be able to deal with the latency issue - i am trying to get a 60ghz 802.11ad embedded setup working - but finding linux drivers for those chips is not easy - there is at least some 60ghz routers out there if i can get those to work though.

Though, programs like virtual desktop seem to work though i'm fairly sure you can't use the oculus software with that.

was also trying to reverse engineer the 60ghz system to allow the open community to get involved with it but that is easier said than done.