DJBOT Horizon Worlds Quest Link Headset Microphone / Oculus Virtual Audio Device MONO not STEREO
It's 2024.. Can we get Stereo? Not MONO? Please consider this feature request.. When users want to input audio via Quest Link Device under Windows I believe it utilizes the only Windows Device on the Recording Tab called "Headset Microphone / Oculus Virtual Audio Device" to do this. Alot of users using Horizon Worlds want to DJ Music via Spotify etc. This is how its done. Yet what most don't understand is its being sent through a Mono 1 channel 16bit 48khz Device Driver? (correct me if I am wrong) After years of testing this it appears it definately MONO as playing any Beatles Stereo panning song results in not ever hearing 1 of the LEFT or RIGHT channels eg. voice of singer. OPTIONS Add a second device "LINE IN" for this which is 2 channel stereo for audiophiles. Add 2 channel stereo to the exiting "MICROPHONE" device. MOST URGENT give us an option to toggle any Noise Cancellation that is done on this device. Most of the quiet parts of music becomes rather GLITCHED lagg sounding most likely due to the filter that has to be applied for MIC users? There really is no need for this using Quest Link. See YouTube Audio Glitch Test: https://youtu.be/rSKav5vO3MU Share your thoughts...
Quest Link USB3 transmit latency significantly higher on Quest Pro
Hey all, I recently got a Quest Pro (and shortly after, a Quest 2) and being the stubborn person that I am, decided to try writing an OpenXR driver for Quest Link to use on macOS and Linux, since Meta does not currently support these platforms (nor do I expect them to any time soon lol). However while writing my own driver, I noticed that the Quest Pro consistently had worse performance. Looking further, I found that with the exact same resolution, encoding settings, etc, Quest 2's USB transmit is a stable 0.5ms, whereas the Quest Pro often crosses the 1ms transmit time. Quest 2: INFO [comp_ql_calc_frame_pacing] Avg: tx 0.575194ms, encode 18.336222ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.479831ms, encode 18.421983ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.482888ms, encode 18.347163ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.480982ms, encode 18.464094ms Quest Pro: INFO [comp_ql_calc_frame_pacing] Avg: tx 1.075382ms, encode 12.934615ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.710841ms, encode 10.299981ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.850958ms, encode 10.371938ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.645109ms, encode 10.543258ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.592482ms, encode 10.271824ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.770167ms, encode 10.140699ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.911711ms, encode 10.275272ms INFO [comp_ql_calc_frame_pacing] Avg: tx 0.556561ms, encode 10.065738ms Both devices are on v47, and `libusb_get_device_speed` returns `LIBUSB_SPEED_SUPER` for both headsets, so in theory they should be operating at 5000Mbit/s. It's worth noting that I'm including the cap'n proto preamble packets, so that's 0.4ms Quest 2/1ms Quest Pro across 3-4 packets (segment sizes + cap'n proto + optional csd + idr/coded slices).
