Hey,
I have purchased yesterday an Android license to uxe Xreal glasses plugged to an Android smartphone (supporting DP Alt-mode), in order to run a cloud computing application where a VM runs flight simulators. The reason I want VirtualHere in this setup is because I can use the Xreal glasses' sensors has headtracking device too if the Windows PC can see them as a USB device, and then use 3-dof inside the simulators instead of just using the glasses for their display.
The problem I'm encountering is the glasses also have built-in speakers. This is perfect when not using USB/IP because the Android smartphone then outputs sounds to them and it's crystal clear. The problem is they are also recognized by the remote computer as an audio device when I enable USB/IP using VirtualHere, instead of the phone,, and the result is the sound suddenly becomes very distorted and cracks; I'm guessing the bandwith and ping degrade it.
When USB/IP is enabled on this USB device, they become the default audio output of the Windows computer. I can go to sound settings and disable the audio part, but then I can get no sound at all, while I did when it was using another device as default before enabling USB/IP. I am aware this is not a very clear explanation, sorry.
Basically my question is: can I make it so VirtualHere distinguishes which parts of the USB device it conveys when there are multiple hardware parts in it? I would like it to not route audio from local to remote, or at least force it into not showing the USB device as a generic USB audio device.
---
Before enabling the glasses in VirtualHere, sounds goes to the glasses from the phone itself and the quality is good with no delay, and the remote computer uses the bottom device as audio output:
https://i.imgur.com/muwC3QN.png
After sending the glasses over USB to the remote computer, they become the default audio output of the computer and the phone can no longer use them directly:
https://i.imgur.com/PJs6lHx.png
Sound is totally broken. If I disabel this device and try to re-enable the other one from the screenshot above as default, I get no sound at all, I'm guessing because the phone no longer sees it has an USB audio device available.
The same issue probably exisxts on VirtualHere servers for other platforms, I just didn't try with my Linux machines yet because usually I would use their speakers and select that using pavucontrol if I am using them (but if I wanted to use the glasses still, this would be an issue too). Android does not offer such easy flexibility.
.
Virtualhere can only redirect entire USB devices. Yes the cracking sound is the network latency.
There must be some configuration setting in the windows client side (not related to virtualhere) but related to sound where you can force the sound output to go elsewhere.
Perhaps disable the passed in Speakers (that are passed in via virtualhere) in Windows Device Manager and that will force it to use another output. I.e in Device Manager right click on that Sound Device Properties Disable. Therefore it wont even appear as an availble output in Windows Mixer
Thanks for the quick answer…
Thanks for the quick answer. Disabling the corresponding speaker device in the Device Manager indeed prevented Windows from trying to use it, and it stays on the default speaker it was using before I passed the glasses using VirtualHere, but I still get no sound coming from the phone or the glasses after that; same as when I just selected another default audio output in Windows while glasses were passed through USB/IP.
I'm guessing the local system (Android) can no longer use the speakers of the glasses once they are redirected by VirtualHere, and won't use its own built-in speakers (which would not be my preferred solution anyway). I can see for instance that if open another mobile app unrelated to the cloud computing one, there's no sound coming out of it, neither from the phone speakers nor from the glasses speakers.
If I "Disable USB audio…
If I "Disable USB audio routing" in Android Developper options, the audio goes to the phone's speakers all the time and not the glasses, so it's not redirected to the remote computer, and I get no cracking sound.
It's not what I would want though, functionally it would be like using another BT audio device instead of the speakers to keep the sound from being sent to the glasses. I want the audio in the glasses via USB routing but without the loop to the remote computer that adds latency and makes it crack. When not using the remote computer but just watching a movie locally, it's also very convenient to have the sound in the glasses without annoying others instead of on speaker, so I would not want to lose the function of the glasses audio.