VOIP unstable on Steam: 'Network saturated'

Was hoping that VOIP would stabilize after Unreal Engine Issues and Bug Tracker (UE-34081) made it into 4.13

However in multiplayer games with more than 2 players are connected VOIP deteriorates (intermittent packets play back) to inaudible levels. Looking at the logs for a session where this occured the logs are filled with:

[2016.10.04-03.29.35:109][934]LogNet:Warning: Dropped 1 packets due to congestion in the voicechannel
[2016.10.04-03.29.35:109][934]LogNet:Warning: Network saturated
[2016.10.04-03.29.35:109][934]LogNet:Warning: Dropped 1 packets due to congestion in the voicechannel
[2016.10.04-03.29.35:154][936]LogNet:Warning: Network saturated
[2016.10.04-03.29.35:154][936]LogNet:Warning: Dropped 1 packets due to congestion in the voicechannel
[2016.10.04-03.29.35:154][936]LogNet:Warning: Network saturated
[2016.10.04-03.29.35:154][936]LogNet:Warning: Dropped 1 packets due to congestion in the voicechannel
[2016.10.04-03.29.35:176][937]LogNet:Warning: Network saturated

My steam config in DefaultEngine.ini is as follows:





I turn on networked VOIP with:

void UAdvancedVoiceLibrary::StartNetworkedVoice(uint8 LocalPlayerNum)
	IOnlineVoicePtr VoiceInterface = Online::GetVoiceInterface();

	if (!VoiceInterface.IsValid())
		UE_LOG(AdvancedVoiceLog, Warning, TEXT("Start Networked Voice couldn't get the voice interface!"));


I was experiencing this in 4.12 and was hoping that it was fixed in 4.13 (haven’t upgraded yet). In 4.12 voip would work for like 1-2 seconds after a player spawned and that was it. We really need this fixed Epic!

Also experiencing VOIP frequently cutting out (to the point of being unusable) with Steam Online Subsystem, even with only one other person connected and no other apps using (any significant) network bandwidth in the background at the time.

Push to talk is disabled in my case, blueprint only setup.

Hey everybody,

Thanks for the feedback. We were able to reproduce the issue on our end and I have submitted a issue ticket regarding it. You can follow its progress here:


Thanks for looking into this. Will keep my eye on the bug ticket.

This problem also appears with the Null subsystem!

Actually having a bigger MaxClientRate (at least 2Mbytes) seems to solve the problem on the Null Subsystem… So maybe the same on Steam? But if it’s a solution in LAN, it seems a bit overkill for internet networking.

Could you expand on the suggested solution? Where is MaxClientRate specified?

MaxClientRate is a setting that can be added to the DefaultEngine.ini file.


But changing it to 2MB sounds incredibly extreme, especially since the default is only 15000 bytes/s. Which is .015 MB/s. I don’t think this is a proper solution for non-LAN, which is what voip is really for.

I totally agree, it’s not a solution for non-LAN (and even in LAN it’s more a workaround than a solution). But it highlights the fact that maybe the “bug” is that voice is not optimized and saturates the network, either on Steam or Null subsystems.

Is there any updates on the progress of this issue? I noticed some time ago, this issue had over 20 votes, but it seems as though it was reset sometime after 4.14 was released.

From what I could see, only an issue pertaining to the Mute list was addressed with the voice interface, but there’s nothing which covers the size of the voice buffer.

Unfortunately, there was an issue where the public tracker votes were reset. I’d highly encourage anyone interested to go ahead and vote on the issue again to get it back up to where it was prior to this reset.

any more progress on this?

The issue is marked as backlogged, which usually means that the developers are focusing their efforts on high-priority crash and blockers.

Keep an eye on the public tracker for updates, however.

Have a great day

Steam doesn’t have a lot of control for the bitrate and therefore packet size of their voice stream. I found it to be 200-300bytes/call with about 8-10 calls/sec when a user is actively talking.

The issue here is related to the Connection->IsNetReady(0) call in UVoiceChannel::Tick. It believes that you have sent too much data in the last period and that the connection is saturated.

This code works from the NetSpeed settings in your ini. You can increase this value, but you should also be taking a look at what other kinds of net traffic are occurring at the same time. If you game is really chatty then upping this value, while valid, may provide a worse overall experience for your users.

The nuclear option

  • comment out the check for IsNetReady so that the voice channel code will always send voice packets no matter what
  • this can at least give you a chance to see how the voice sounds, although it will probably be choppy
  • if things work just fine consistently I would expect the engine to have a bug of some kind

The slightly better option

  • make the Steam voice packets “reliable” by changing FVoicePacketSteam::IsReliable to return true
  • this will guarantee the packets get sent, but will probably be choppy if IsNetReady still says you are saturated

The best option

  • evaluate what your net rates are and optimize your network traffic
  • modify the values below, within reason, to see if it helps

You can try setting this value higher


Which is also affected for each client by these values


These values are set/negotiated when a player connects to the server (look for NMT_Netspeed), but are clamped to server limits.

To be honest this system of netspeed values are pretty overwhelming and I don’t always have a great grip on it. It comes and goes based on how deep I’m in the net code.

You can see the decay in the network saturation at the end of UNetConnection::Tick with the calculation for QueuedBits.

This would be the first step. Making sure that the voice traffic even leaves the client and/or server so that others have a chance to hear it. If the error messages here go away and things are still choppy/bad, we can address them next.

The “Opus implementation” used by the NULL interface has a lot more control of bitrate, but that is in a version of the code that hasn’t made it to the main branch yet. I think there is a lot more flexibility in audio quality there that Steam doesn’t expose.

How can I download the project that reproduce the issue?