We want to play with options for delaying Vivox communication for our experimental study. I was thinking about something like Unity Transport’s Debug Simulator options for Packet Delay, Jitter, and Drop Rate, but more geared towards Vivox.
We need to introduce these delays from the side of individual clients. Of course, we may not need a complex beast like Debug Simulator; just being able to introduce a delay in the audio stream should be enough for now.
clumsy is a tool on Windows that can probably be filtered to specify traffic from Vivox and induce lag, jitter, and dropped packets. I don’t know that it can be configured by a tool unless you use something like AutoHotKey. (EDIT: it looks like clumsy can take command line args or a config file, but it requires reading the code to understand how to use it. There is no --help usage printout.)
Otherwise, using Vivox Audio Taps and OnAudioFilterRead in a component script you could simulate network issues by modifying the incoming audio yourselves with your own buffering (tip: ring buffers). Be warned that using OnAudioFilterRead can lead to discontinuities in all game audio if your garbage collection pauses are too long. So be careful with memory allocation and schedule garbage collection often to avoid those discontinuities if you go that route.
From my understanding, we don’t allocate memory on the audio thread, except for the first iteration, where an int16 buffer is made for denormalising the float samples.
Effects on (asynchronous) collaboration between participants in a virtual environment when there is an uneven delay on one side. It’s part of my PhD thesis. There’s a little more technical info on https://discussions.unity.com/t/946077 if you’re interested!
Unity Transport Debug Simulator should not be able to affect Vivox network packets.
You can share a Windows ethernet connection over WiFi, connect to that WiFi network with the Quest, then run clumsy on the Windows machine with the filter “inbound” to affect the Android traffic.
I think simulating the conditions client-side with audio buffers is the most straightforward and controllable way though.
I can’t hotspot private ethernet; that could have been the best. I also need to make it single out clients. I could do this on the receiving clients’ side – the rest of the logic would generate data resembling lag, which may be ideal. However, just for curiosity’s sake, I want to confirm that there isn’t a mechanism on the sending clients’ side to do this, at least in the Unity VivoxService API.