I have been trying several methods now, for receiving and sending audio streams with Java and C++, and they have worked OK, but delay started queueing up. I had some problems understanding what I was doing wrong or what I needed at first, after some reading I found that I needed to have a jitterbuffer, so having little info, I started working with a library instead as it had a jitterbuffer included.
And it has increased performance a lot, as it delays packets so the network buffer etc does not queue up as much as before.
So I was wondering, what can I expect as latency having RTP over UDP and a dedicated router/network for the devices? I have about 300-1000ms delay, is that an Ok average?
The 0,3-1s delay is from a phone to another, when streaming from phones to pc I think I have as low as 0,1-0,3s, is this possibly related to the phones being cheap phones with "low" audio, network and general processing power?
what can I expect as latency having RTP over UDP
Measure RTT (round trip time) that packets travel between endpoints, that's the best possible time you can get. Then there is variance in RTT time and jitter buffer is there to handle this kind of network delays. Usually in VoIP applications jitter buffer adapts dynamically to the rate of packets that being queued from the network. So, if your RTT is in the range of 50ms-250ms and if you send 40ms of sound per RTP packet then you would get around 200ms latency. In testing I found that 200ms is not that bad. Here's how I'd estimate delays: if RTT is between 50 and 250ms then jitter buffer would have to adapt to worst case scenario and assume RTT of approximately 250ms, or 125 ms one way. Then there is extra delay of buffereing on sender side. If you send 40ms of audio per packet then you need to add 40ms extra delay, which adds up to 165ms, plus there is processing here and there, 200ms wouldn't be bad in this case. If you use Android phones expect that audio playback on android phones may add some extra 200ms of delay or so (totally depends on android version and phone model). Yes, that's right: when you queue to play sound to the os you may actually hear sound only 200ms later! iPhones have much smaller delays when playing back speech (I'd expect something in the range of 20-40ms). You really start to notice delay in speech conversation when it grows over 300-400ms. I'd probably get best quality in voip if you use WebRTC library.