<div dir="ltr">I have a streaming uncompressed audio application.  It is a round trip path from node A to node B and then back to node A.  A is setup as a client.  B is setup as a host.  The links can have up to three 48k/24bit PCM audio channels - thus 1.1 Mbit each, plus one setup/control channel with negligible bandwidth requirements.  This application cannot have errors, so enet packets are all setup as reliable.<div><br></div><div>I have tried these cases:</div><div><br></div><div>(1) One audio channel, no packet drops, no network delay - works great.</div><div>(2) One audio channel, 0.85% packet loss in each direction, 120ms network delay in each direction - works great with ~900ms buffer at both A and B</div><div>(3) Two audio channels, no packet drops, no network delay - works great.</div><div>(4) Two audio channels, 0.85% packet loss in each direction, 120ms network delay in each direction - fails consistently with not enough throughput.  Thus, the buffers at either node deplete relatively quickly (~2 seconds) and the stream is broken, falls behind.</div><div><br></div><div>I have set both enet hosts up for infinite bandwidth.  I believe the network bandwidth capacity is very large, > 100 Mbit.  I setup the network conditioner (that is simulating the packet loss and network delay) to have 60 Mbit bandwidth...so I don't think it is the problem.</div><div><br></div><div>At both nodes I have enet_host_service setup in it's own task, so I believe enet is always able to perform any necessary work.</div><div><br></div><div>Any ideas?  I see there is some sort of throttling algorithm in enet, but it appears to be used to limit unreliable communication (?).  Any ideas?</div><div><br></div><div>Thanks,</div><div>Chris</div></div>