alvr-org
bug: USB Wired mode doesn't work on master
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.
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) Intel Core i5 11th gen 16Gb DDR4 RAM AMD Radeon RX 6800
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.
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.
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.
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.)
What operating system/version of ALVR are you using?
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
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
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.
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.
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
good news! as of the v21.0.0-dev01+nightly.2024.11.23 build, usb works... although a wifi connection is required for the first-time connection, then it is smooth full-res vr over usb!
@FoxbitDreamtail have you tried with the integrated support (toggle in the Devices tab)? The other methods will be deprecated after the next stable release
@FoxbitDreamtail have you tried with the integrated support (toggle in the Devices tab)? The other methods will be deprecated after the next stable release
sorry, I misunderstood how the new system worked... it works strictly over usb but I would need to approve adb every time my quest starts up... it is mildly annoying but it is nowhere near as annoying as the audio situation, namely that the audio devices do not automatically switch to the quest on connection, there used to be an old on-connect script but I don't think it would work anymore because the audio device's name was changed, I would fix up the script myself but I cannot find the new device name...
About audio, that was my concern as well. But @Meister1593 should be the one to refer to
Is this still relevant? I know the issue itself got fixed by integrated adb support, but this should also break remote (i.e. separate network) streaming configurations, which we still want to support.
Is this still relevant? I know the issue itself got fixed by integrated adb support, but this should also break remote (i.e. separate network) streaming configurations, which we still want to support.
Ideally, you should be able to just connect over The internet using like a global area network service like Zerotier One To connect the two devices as if they were on the same network.
Ideally, you should be able to just connect over The internet using like a global area network service like Zerotier One To connect the two devices as if they were on the same network.
Obviously, the point is that they might still not be able to discover each other due to limitations from the vpn/bridging solution. So you might have to still manually specify the address in the local network. The question was whether that was still broken.
Obviously, the point is that they might still not be able to discover each other due to limitations from the vpn/bridging solution. So you might have to still manually specify the address in the local network. The question was whether that was still broken.
Unfortunately, I myself can't test that because I'm on Linux and with Linux I am very limited in my global area network solutions. I only mentioned Zerotier One because it is both compatible with Android and Linux and it's the only option I know of. Unfortunately, unless you're just doing that with your quest, you would be paying a monthly subscription... Also, Zerotier One is not a consumer grade software. It is a professional grade software used for managing organization network connections. Unfortunately, there is no consumer grade solution available for Linux(to my knowledge)...
Not actually an issue I think, I'm pretty sure you can emulate all variables that matter by simply using legacy wired mode and disabling wifi on the headset. Or if one really cares one could set up some bullshit vlan segmentation and use a vpn between two local pcs.
Not actually an issue I think, I'm pretty sure you can emulate all variables that matter by simply using legacy wired mode and disabling wifi on the headset. Or if one really cares one could set up some bullshit vlan segmentation and use a vpn between two local pcs.
The VPN between two local IPs was what I was thinking of. The USB option probably needed to be reworked anyway as it wouldn't be used for the vast majority of users in that way.
Pretty sure it's fixed now and can be closed Concern about audio not switching by default is still there, but i'm researching on how to make it work (wireplumber integration)