-
-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: USB Wired mode doesn't work on master #2376
Comments
Do you use UDP or TCP for streaming? For me, only TCP works with the ADB Forwarding method |
USB-Wired Mode does work, however it's a bit of a hassle to set up, First, you have to change the IP of the device you want to use to 127.0.0.1, Next, you need to find some way of forwarding two separate addresses through ADB, And then finally, you need to use TCP In order to get any sort of image to show in the headset. After you do all this, in my personal experience, it's a much worse experience than if you were to just connect two devices on the same router. Because in this exact same setup, but wirelessly using like a 12 year old Wi-Fi router that only supports Wi-Fi 5, I was able to get a smooth, albeit Compressed image in Beat Saber and a few other games that I play just fine but over USB there are some serious skipping problems and Input problems in conjunction with visual fidelity issues as well Such as in the main SteamVR Environment, if you turn your head too fast, you'll see the black borders of the previous frame. Just know that I was using a USB 3 cable while I was doing this. The slowest speed of USB 3 gives you 5 gigabytes per second that you can utilize. This should be fast enough to send correct controller input and headset input while also sending lossless screen resolution back to the Quest 2 at ~85-90fps And if I am greatly mistaken, Then please tell me otherwise or tell me off for it because my only 500Mb/s Router from around 2012 is completely outclassing the USB method by an order of magnitude in spite of it having a fraction of the bandwidth. By the way, this was all done in today's(2024/9/10) nightly build On Linux Mint 21.3 with the following hardware. Asrock Phantom Gaming 4(using onboard USB-C port for testing) |
Funny thing. At one point something I did looked like it worked but in reality it just didn't. So basically I tried to, you know, do the responsible thing and change settings before doing anything else. And one of the settings I changed looked like it worked until I looked at the IP the quest was using and it was using my router. So essentially I'm sorry but Changing the amount of frames that the server is able to pre-render before before displaying from 1024 to 256 sadly will not help the spikes in encoder latency, But it may help on lower end networks, since in certain scenes in Beat Saber I was getting even greater graphical clarity than I was before. |
Must be your settings then. I was using ALVR wired with the best possible picture quality and latency comparable to VD at 90Hz. Quest 3, near 3K resolution, 750mbps. Maybe you're trying a bitrate that your GPU just can't handle? Wireless on the other hand, ALVR worked very poorly for me on Wifi 6 router, compared to alternatives. |
What operating system/version of ALVR are you using? I'm using the nightly from yesterday to base my understanding off of. I was using default settings in ALVR, Literally nothing changed. It works better on my 500 megabytes per second, 2012 router than it does over USB-C. And I do not know why that is the case(Also, it should be noted that I am on the Meta Quest 2, not the Oculus Quest 2 or the Meta Quest 3. The reason I'm mentioning that distinction is because in between the two, there was a major hardware revision which changes the ADB name.) |
I'm using the previous version v20.10.0 on Windows, maybe some recent commits broke some stuff. GPU is RTX 4070 Super. |
This issue is not reproduced on stable releases because they are being created from v20 branch, which doesn't have this issue. Something between master and v20 is wrong, and it could be months away, I would check commit with issue at least as far back as mdns introduction goes (which is present only on master branch, not releases) |
Other people report that also nightly has no issues so we should investigate this with them |
it connects fine if wifi is on on the headset and it actually seems to go wired in that case and doesn't do a fluke connection over wifi. it only breaks if wifi is off, which likely isn't the case for most people |
Ideally, the whole point of having a wired connection is to avoid wifi entirely. So, I don't understand why this would be a requirement. Also, the last nightly I ran did not have this issue, but it had major performance problems and major graphical delegation and stutters, I will be trying again tonight with fnaf help wanted and kill it with fire VR... I may also try to use beatsaber, which is my normal go-to test. |
yea? If it weren't a bug I would've closed the issue. My comment was just about trying to bring forward all relevant information to debug the issue. And also to hopefully clear up any confusion as to why some were not encountering the bug. I don't really understand what I said that indicates that it would be an intended requirement of any kind. |
Hey is there any update to this? I've tried everything including using both the IP that shows on the screen along with 127.0.0.1 and idk if this is just me but my hostname is not a XXXX.client.local mine is just a XXXX.client |
@DecibelHZ we merged integrated USB support. Check the latest nightly |
It works on v20 (20.10.0) but not on current master
If you disable wifi, it won't ever connect to pc, and if you enable it - it will connect through wifi regardless of manual ip settings.
Can't seem to bisect specific commit where it stops working, needs investigating.
The text was updated successfully, but these errors were encountered: