fix(connection): 🐛 Try localhost if broadcast fails, fixes wifi being required for cabled

[Meister1593]

This makes so that if client can't broadcast, it will try to do announce on localhost.
Thus, making wifi requirement being needed on alvr being optional.

I also added and changed some hud signs, as well as removed wiki line about client discovery - apparently if you set ip on server and have adb working, it doesn't matter if you have client discovery enabled or not, it will connect to wired in either case.

[zmerp]

Looks amazing! 😄 there is a thing I would change. I would like to hide as much as possible socket details in connection.rs. So you can make two methods announce_broadcast() and announce_local(). Even better would be to handle the local fallback all inside the AnnouncerSocket, but I'm ok if you would like to show the in between status on the HUD.

[Meister1593]

Looks amazing! 😄 there is a thing I would change. I would like to hide as much as possible socket details in connection.rs. So you can make two methods announce_broadcast() and announce_local(). Even better would be to handle the local fallback all inside the AnnouncerSocket, but I'm ok if you would like to show the in between status on the HUD.

Done. Changed to separate functions, left hud elements and distinction so people can see if they are connecting via cable or not :)

[Meister1593]

I think i may have accidentally did workaround over broadcast and if i remove local connect, nothing will change
as it's... well
udp
and adb is tcp...
i may need to think about this how to do it properly

[fred41]

I think udp broadcasting is not working via adb tcp forwarding,
but for disabled wireless on client (with USB3 link connected), you could do the following in sockets.rs:

pub fn broadcast(&self) -> Result<()> {
        if LOCAL_IP != Ipv4Addr::UNSPECIFIED {
            self.socket.send_to(&self.packet, (Ipv4Addr::BROADCAST, CONTROL_PORT))?;
        }

        Ok(())
 }

So with wireless enabled, everything works as usually. With wireless disabled, we just don't try to broadcast.
This works very well on my system, so maybe this is a possible approach?

[Meister1593]

I think udp broadcasting is not working via adb tcp forwarding, but for disabled wireless on client (with USB3 link connected), you could do the following in sockets.rs:

pub fn broadcast(&self) -> Result<()> {
        if LOCAL_IP != Ipv4Addr::UNSPECIFIED {
            self.socket.send_to(&self.packet, (Ipv4Addr::BROADCAST, CONTROL_PORT))?;
        }

        Ok(())
 }

So with wireless enabled, everything works as usually. With wireless disabled, we just don't try to broadcast. This works very well on my system, so maybe this is a possible approach?

Thanks for suggestion, i changed my existing code to not assume that there is broadcast available on TCP cabled connection

I tested with: WIFI on, WIFI off, WIFI on different network, with and without client discovery - all works correctly as it should.
All what streamer should have is tcp and localhost ip set in it to be able to stream via wire regardless of how it's connected.

[Meister1593]

Without WiFi enabled it might do a couple of attempts to properly connect, but otherwise it does connect just fine after that.

[Vixea]

merging as is after I test it locally

[XenoPL]

Hi, could this change improve support for wired ethernet connection via USB adapter (router<->usb ehternet adapter<->headset)?
I couldn't make my PC connect reliably with Pico4 with ALVR. Headset alone has no problems with internet access and streaming some videos, but ALVR client never detects assigned IP, connection to the PC is very choppy and laggy (it's unable to keep up even with Steam dashboard). Possibly to very high usage of HMDs CPU.
PC is connected to TPLink Archer VR2100 vDSL router with 1GBps ehternet cable.
I've tried two different usb-c 1Gbps LAN adapters
https://www.amazon.pl/dp/B09MQDWP6H?psc=1&ref=ppx_yo2ov_dt_b_product_details
https://www.amazon.pl/gp/product/B086SV2FK4/ref=ox_sc_act_title_1?smid=A2R2221NX79QZP&psc=1
and USB-C cable extender:
https://www.amazon.pl/dp/B0CL52SBLP?psc=1&ref=ppx_yo2ov_dt_b_product_details

[Meister1593]

Hi, could this change improve support for wired ethernet connection via USB adapter (router<->usb ehternet adapter<->headset)? I couldn't make my PC connect reliably with Pico4 with ALVR. Headset alone has no problems with internet access and streaming some videos, but ALVR client never detects assigned IP, connection to the PC is very choppy and laggy (it's unable to keep up even with Steam dashboard). Possibly to very high usage of HMDs CPU. PC is connected to TPLink Archer VR2100 vDSL router with 1GBps ehternet cable. I've tried two different usb-c 1Gbps LAN adapters https://www.amazon.pl/dp/B09MQDWP6H?psc=1&ref=ppx_yo2ov_dt_b_product_details https://www.amazon.pl/gp/product/B086SV2FK4/ref=ox_sc_act_title_1?smid=A2R2221NX79QZP&psc=1 and USB-C cable extender: https://www.amazon.pl/dp/B0CL52SBLP?psc=1&ref=ppx_yo2ov_dt_b_product_details

Honestly, i'm not too familiar with this kind of setup...
If i understand it correctly, this can only work in case if ALVR will attempt to directly connect by ip to headset (that's all it needs, this pr just changes so that it doesn't require multicast over network announce packet for connection)

[Meister1593]

If you can get ip of headset when it's connected like that and put it into alvr, it should work.

[XenoPL]

Thanks for an answer, I got it working after few tweaks. Point was I took effect for a cause. It made HMD stutter because improved bandwidth and latency let ALVR kick bitrate to the roof. Once I reduced requested bitrate to ~120-130Mbps it made actual bitrate to be in 160-210MBps range which is what Pico can decode via hardware and keep its tiny CPUs from being overloaded.
Nice FPS boost in games was nice bonus too.

[Meister1593]

Fyi i can easily decode 800 mbps h264 and 200-220 HEVC on pico 4 pro, on linux, with type-c cable