New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Voice audio issues with 2023.3 and new orchestrator #144
Comments
If it turns out that #144 has been fixed we should also check these points again. Crossing finger that they'll also be fixed. |
Confirmed fixed. |
Re-opened this. The second and third bullet point were indeed fixed, but the first one not yet. |
There were two things that we tested this and last week:
|
Jack and Ashu tested on
|
For reference: @jvdrhoof is also seeing some unexpected latencies, sometimes, with a completely different setup: point clouds over socketio or webrtc. Sometimes (but not always) he is getting latencies in the This may be a red herring, but it may mean that we are looking at a problem that has nothing to do with audio but is actually in a completely different place. |
(and, completely beside the point: @ashutosh3308 please reserve backticks |
On the branch, repeated Reported latency on Vrtiny time was |
Repeated the exact same experiment, with very similar outcomes. |
Did another one today. Same setup. Delay was variable, and noticed that as measured latency went up reported latency also went up, and vice versa. It almost seems as if the measured latency is approximately twice the reported latency. But this seems ridiculous.... |
Another observation: on the receiver side, if we compare On the sender side, in Assuming a millisecond or so for transmission all the reported numbers seem to match: |
Disabled the spatializer. Makes no difference: still about 200ms extra latency perceived versus measured. |
But now it seems that the "DSP Buffer Size" we set in Project Settings -> Audio sticks. And it was set to "best performance" previously. I have set it to "Best Latency". Difference between perceived and measured latency goes down to So this does not explain the 60ms decrease in perceived latency. And it doesn't explain where the other 140ms go. Need to test Mac-to-Mac, to ensure were not also looking at some Windows problem. |
Experimented with Perceived latency goes down to |
Go the other way, Record latency= Perceived latency is around |
Repeated at home, Mac->Windows ( I did notice that both machine had |
Set both machines to Project Settings -> Audio -> DSP Buffer Size -> Best latency. Make very little difference. |
Set both machine to mono, no spatialised, no virtual effects, no audio suspension. |
Next experiment: Mac to Mac (using |
Unfortunately all these experiments show is that various theories we had are all wrong:
|
Tried with a built player (Mac->Mac). Again doesn't make a lot of difference: reported So there is a lower discrepancy between reported and measured, |
Tried with a built player on Windows too ( Reported latency |
Tried a different way of measuring: don't do an audio-only capture but record a video. On the voice receiver machine select the Load the video into Logic, so we can examine the waveform and the video with the VU meter at the same time. The VU meter is pretty much frame accurate... So something in Unity knows when it is playing out the audio...... |
Added a "DIY VU meter", by computing the RMS in the buffer. Recorded it with a slo-mo camera. |
The DIY VU meter improved (sort-of) by using |
But accidentally found something very interesting, after a session was running for a long time: even with both input queue sizes set to 2 packets the reported (and perceived latency go up and up and up...... Seems like packets re being held up somewhere in the network or in AsyncTCPReceiver? |
That was a red herring. At least, it wasn't related to what we're looking for. The queue lengths were long, and the first queue was non-dropping. That may be something we want to address, but it's not related to the extra 100-200ms latency we perceive. |
Decided to go back to Unity 2021, just to see whether maybe this problem has been present for a long time but we just didn't notice it. First try was branch |
Tried with newly created branch This branch has exactly the same problem as the current situation: the perceived audio latency is about I'm now starting to think that we never actually measured audio latency, and alway just looked at the reported number. |
@ireneviola also isn't sure we ever really measured this. |
Ok. We know where the problem is (on the Unity playout side), and we know how to work around it (by adjusting the audio playout clock to be slightly ahead of where we actually want it). But I'm not going to fix it now. All the groundwork is in place, and the structure of the voice pipeline and |
We're seeing all sorts of different issues with voice audio:
latency_ms
in the stats: output...We need to investigate what is going on.
And let's use this issue to document whatever we find.
The text was updated successfully, but these errors were encountered: