martindevans
commented
6 years ago I typed all of this up and then noticed you're using an older version of Dissonance - the code snippet you show was changed in Sept 2017. Those changes included some fixes to playback quality in the face of terrible network conditions which seem like they could be relevant to you. I'd suggest upgrading to the latest Dissonance and seeing if that fixes the problem.
In case that does not fix the problem (or you're just curious) here's my original reply:
Jitter buffering protects against changes in latency between one packet and the next (aka jitter). If we played out a packet as soon as it arrived the next packet would have to arrive exactly on time, any delay at all and it would be too late because we must supply audio to the speakers on time. A jitter buffer deliberately delays packets slightly (worsens latency) to ensure there's always a packet available when needed (improves quality). In Dissonance packets are added to a buffer as soon as they arrive and a timer is started, after some delay (the _jitterDelay value) playback begins. Since playback and capture are both operating at the same rate the buffer should then keep approximately the same number of packets in it at all times, only varying due to jitter in packet delivery/playback time. We also have a mechanism in the playback system which slightly changes playback speed (within a few percent) to deliberately expand or shrink the buffer as needed (so if jitter gets worse as playback proceeds the buffer can slowly be expanded to add more delay, and tolerate the extra jitter).
What exactly does the jitterDelay variable represent?
On the line you highlighted:
jitterDelayis the amount to delay the audio before playback._jitteris a struct which measures standard deviation in the packet delivery time, this is a rough estimate of network latency jitter.- '2.5` is the amount of jitter we protect against. Assuming the jitter is normally distributed this expands the window to protect against 2.5 standard deviations of the measured jitter (something like 98% of normally distributed values would fall within this range). In reality latency is not normally distributed so this isn't a perfect system but it should be an overestimate so we're safe.
InitialBufferDelayis the value to use if we don't have a good measure of the jitter yet, it's a fairly high value so it should generally be safe to start at that value and then reduce the delay down as we get a better measurement of network conditions._jitter.Confidenceis a value from zero to one indicating how many jitter measurements we have taken. We're linearly interpolating fromInitialBufferDelayto_jitter.Jitter * 2.5fbased on confidence.
We were seeing values reach about 1.0 and this is when audio quality would get completely butchered. Hard limiting the jitterDelay value to .1 or 100ms then the audio stream would sound clear, but it would be delayed from the other person talking.
For a value of 1 second the jitter measurement must be measuring 400ms standard deviation in packet delay times (which is truly dreadful) - can you tell if this is a real network problem or if the the jitter meter is completely broken?
Were you getting any other warnings when playback was bad? For example if the delay gets very large there's a message Encoded audio heap is getting very large (N items) printed out (threshold is set at 40+ items, or about 1.6 seconds of delay at the default settings). If you could send me some examples (martin@placeholder-software.co.uk) of bad audio that'd be handy. If you can get a log that'd be fantastic.
sayangel
We recently had a case where someone had really bad audio quality so we investigated why it was sounding so bad. After messing with some of the jitter parameters it seems like we can improve the audio quality at the expense of lag accumulation.
I'm wondering if there's a reference for the jitter algorithm that Dissonance is using in particular this line of code in
SpeechSession.csI understand the estimated delay starts at 100ms and then adjusts. What exactly does the jitterDelay variable represent? We were seeing values reach about 1.0 and this is when audio quality would get completely butchered. Hard limiting the jitterDelay value to .1 or 100ms then the audio stream would sound clear, but it would be delayed from the other person talking.
Any direction to understand the jitter compensation process would be appreciated. Happy to provide samples of the bad audio via email just send me an email to angel@insitevr.com