.

[martindevans]

If you're submitting an issue please make sure to fill in the issue template, it's there so I don't have to ask these same questions every time!

• What version of Dissonance are you using? (Check Assets/Dissonance/changelog)
• What version of Unity are you using? (Check Help > About Unity)
• What editor Operating System and version?
• If you problem is happening in build, what platform is it built for?

[hdev72]

another thing can help, when problem happens i can hearing my voice from my speaker, not in other side (I hear very weakly and with a small volume)

[martindevans]

EventQueue: Large number of received packets pending dispatch (12). Possibly due to network congestion (last frame was 3.9613ms) (only some times)

This error means that a lot of packets arrived all at once, but your frame rate is fine so it wasn't due to that. The problem is likely due to something in the network system causing congestion and a large number of packets arriving all at once.

Are you monitoring network statistics in Mirror to check if the network connection is fine overall?

[martindevans]

you know the LAN has no problems with packet loss.

That's (mostly) true for a wired LAN but it's definitely not true for wireless LAN!

Dissonance has a slightly different meaning when it talks about packet loss than what you expect. Audio is playing back at a fixed rate so if a packet is delayed it can arrive late enough that the audio in that packet should have already been played - Dissonance counts this as a loss.

That is why I was asking about the EventQueue: Large number of received packets pending dispatch (12). Possibly due to network congestion (last frame was 3.9613ms) message - that means lots of packets were all delivered at once (due to some factor external to Dissonance) and that could cause them to count as "lost" packets.

20% of the time when I stop and start the client I lose the packet, for example I do this behavior 5 times with no problem and the 6th time im getting packet loss near the 50%

Unfortunately I couldn't hear any sound in your demo video, I assume when the packet loss number is high you cannot hear incoming voice?

when client connect can i clear previus packets queued? a cleanup

I'm not sure what you mean, sorry.

[martindevans]

These are the logs that occurred

All of these log messages are symptoms of the same problem - lots of packets are delivered together, causing many other problems. We really need to diagnose what is going wrong in Mirror to cause what is causing these huge delays.

As a workaround, can you try loading into the scene with the Dissonance GameObject disabled and then enabling it after a short delay. If the problem is caused by something in your loading process that might work as a temporary workaround.

Is there a setting so we can hear delayed packets?

No. Audio has to be played in order and packets which are dropped due to high delays are too late to be played because the point in time when they should have been played has already passed. Playing them later wouldn't make any sense (it would just sound like a jumbled mess).

I don't know which one refers to the server cpu and which one refers to the client cpu in settings help notes. (Frame size and Audio quality)

• Audio Quality - has no effect at all on server CPU usage. You're safe to raise that up unless your clients are extremely CPU/bandwidth constrained.
• Frame Size - A smaller frame size means more packets are sent per second, which increases server load. So Large frame sizes are the right choice for you.

[Dissonance:Playback] (10:28:37.624) SpeechSession: Detected oversized buffer before playback started. Jitter:0.0247042ms (1) Buffered:240ms Expected:62ms. Discarding 178ms of audio...

When Dissonance is about to start playing some audio it delays it a little bit before starting playback (this is called jitter buffering), it chooses a buffer size (62ms in this case) and then each frame it checks if that much time has passed and then starts playback.

This error means that when it checked the buffer had 240ms of audio in it, even though there should only be 62ms. This is another symptom of the issue with large amounts of audio buffering up in the network and being delivered all at once.

... why? (Discarding 178ms of audio...)

There are two choices in this case when the buffer is grossly oversized: play back all of the audio or throw some away. If all of the audio were played back then the playback would be 178ms behind where it should be, so the issue that caused over-buffering (usually just a transient issue) would cause a persistent lag. Latency is the most important aspect of VOIP quality, so keeping that large delay is a worse impact on quality than simply discarding the audio anf getting back into sync.

Remember that this shouldn't ever happen - it's just a last-chance recovery system to attempt to cope with something going seriously wrong in the network! We should focus on trying to diagnose the problem with the networking rather than tweaking the recovery mechanism.

[martindevans]

SpeechSession: Detected oversized buffer before playback started

When you receive these errors do you always/usually also get the error EventQueue: Large number of received packets pending dispatch around the same time (probably just before)?

I'm using kcp (mirror) and want to try other things to transport, maybe it will solve the problem, do you have any suggestions for transport?

Any Mirror transport that supports Unreliable packets should be fine. e.g. Ignorance, LiteNetLib, Steam, KCP, Mirror WebRTC. I know a lot of people have used Ignorance successfully before.

SimpleWebTransport

SimpleWebTransport only supports Reliable packets, this isn't really suitable for voice chat (it'll work better in ok conditions, but will make very bad conditions much worse due to the delays incurred due to reliability).

[martindevans]

It's been used successfully with Dissonance for a long time (back when we first release Mirror support we actually required Ignorance).

[hdev72]

Please completely delete this issue. I had asked misleading questions that confuse users.