I am a very happy user of VirtualHere. My setup is as follows:
- VirtualHere server: Raspberry Pi 4B 8GB RAM, running
vhusbdarm(generic build) release 4.7.3 on a 32-bit Raspbian GNU/Linux 11 (bullseye), with 64-bit enabled kernel (boot parameterarm_64bit=1) - Network: Gigabit Ethernet copper network (with a switch in between)
- VirtualHere client: Intel Core i7 6700 32GB RAM with an Nvidia GeForce RTX3060, running
vhui64release 5.8.2 on a Windows 10 64-bit with the latest updates applied
Unfortunately, in the following condition I am experiencing random yet frequent (once every minute or so) resets of the USB bus:
- the following devices physically attached to the VH server:
- a PXN V9 steering wheel (with pedals and gear shift), which is used by the VirtualHere client
- a wireless Logitech K400 Plus keyboard+touchpad, acting as a local input device only (i.e., no relationships with VirtualHere)
- streaming from the Windows host to the Raspberry using Sunshine and Moonlight, at a preset bitrate of 40Mbps and a resolution of 2560x1440, 60 FPS (the Sunshine server has the same resolution 2560x1440@60, whereas the HDMI output of the Moonlight client is set at 3840x2160@60)
- playing Euro Truck Simulator 2
In short:╔══════════════╗ ╔══════════════╗║ Moonlight ║ streaming ║ Sunshine ║║ client ←─╫────────────────────────────╫─── server ║║ ║ ║ ║║ RASPBERRY ║ ║ WINDOWS ║║ ║ ║ ║║ VirtualHere ║ USB over IP ║ VirtualHere ║║ server ┌──╫────────────────────────────╫→ client ║╚═══╤═══════╪══╝ ╚══════════════╝ │ │ K800 PXN keyboard V9 wheel
What I see is:
- the wheel becomes unresponsive for a short while (usually 1-2 seconds) then resurrects, causing unwelcome sudden turns in the game
- the wheel status LED blinks shortly, indicating a hardware reset happening
- the Raspberry kernel (VirtualHere server) logs messages similar to the following:
usb 1-1.2.2: reset full-speed USB device number 28 using xhci_hcd - every other devices keep being responsive
(Mostly) ruled out issues:
- power: the steering wheel is attached to a USB hub with an external power supply; the hub itself never seems to reset
- single-TT vs. multi-TT USB hubs, as extensively discussed here and here: the wheel is the sole and only USB device connected to the USB hub, which I assume to be enough to avoid protocol underruns caused by the TT bottleneck. For the sake of completeness, the wireless keyboard is directly connected to the Raspberry instead: I assume this also triggers a Transaction Translator, but this time is the Raspberry's internal one and, once again, for a single device only (the keyboard itself). To further complement the picture, a USB 3.0 flash drive is also connected directly to the Raspberry; it does not perform any (intentional) transfers during the session and I guess it does not involve any TTs
- CPU contention: CPU usage never exceeds 35% on the Raspberry (VirtualHere client) in the aforementioned scenario; usage is of course higher on the Windows machine (VirtualHere server), but never saturates. Setting the nice priority of
vhusbdarmon the Raspberry to an exceptionally high value (-20), as well as setting the priority ofvhui64on the Windows machine to an equally high value (Very High) does not help; similar arguments have been described in this topic - USB resets caused by events that are local to the Raspberry: configuring the
onResetevent handler on the VirtualHere server (Raspberry) to ignore reset events received from the VirtualHere client changes the logged kernel events to:Executed "" for onReset
In this condition the steering wheel never resets (i.e., its LED never blinks), thus confirming that resets are not originated by the Raspberry, but still it loses its function for the mentioned time window (1-2 seconds).
Additional context information:
- as many other similar devices, the wheel presents itself as a full-speed 12Mbps device
- it exposes 3 interfaces on a single USB port: a joystick, a keyboard and a mouse; I am not really sure about the impact in terms of consumed resources (bandwidth), but I suspect that it just accounts for a single 12Mbps device
- audio/video streaming (Sunshine/Moonlight) never glitches
- auto-find is disabled client-side: the server's (Raspberry) IP address is statically configured instead
- the latency recorded by the VirtualHere client is steadily below 2ms; however, interestingly, it occasionally spikes close to 10ms while in-game (a similar phenomenon has been described in this topic)
Interestingly, the issue does not occur if I quit the driving session and return to the main in-game menu, which still has a complex 3D model continuously rendered in the background: the streamed scene keeps changing (so there is quite a lot of data flowing) but, if I keep the game in the background (with the 3D model still moving and consuming CPU, GPU) and I open the Game Controllers panel of Windows, the wheel does not miss a beat; VirtualHere does not record any latency spikes either, despite the scenario being substantially similar to the driving session.
So far, I am inclined to think that the steering wheel driver is very sensitive to latency fluctuations, but:
- it is unclear why these fluctuations occur in the first place, especially given that they never happen while the main in-game menu 3D animation is rolling, despite it being equally resource (CPU, GPU, network) demanding as regular driving
- the wheel itself does not require any specific drivers (it uses those supplied with Windows): it is its vibration function that does
Besides reducing the set of potentially latency-sensitive functions, for example by disabling the wheel vibration (which I will soon consider testing), I am not really sure how to work around this issue.
Thank you very much for reading so far.
.
If that still fails i think its actually a pi4 issue. I have a OEM customers and the wheel was causing trouble with the pi4, they switched to pi5 for their systems and no problems.