3 ms·
> when was the last time you made a call that was full analog/PRI? Probably 15-20 years ago? That would have most likely been over DECT, though, which adds 10
by lxgr 2y ago
> when was the last time you made a call that was full analog/PRI?
Probably 15-20 years ago? That would have most likely been over DECT, though, which adds 10 or so ms by itself (our wired landline phone was in a slightly awkward location :)
> Did you notice that cell phones had higher latency than landlines?
Compared to landlines, the most noticeable aspect of GSM wasn't the latency (unless the person on the other line was right next to me, in which case there was an echo), but rather the absolute potato quality compared to both G.711 landlines and modern VoIP codecs.
> mainstream calling isn't willing to send 200 packets per second of 5 ms of samples
Yeah, that would probably be too much overhead for most applications. But now you got me wondering: Do video calls have lower latency audio (assuming the codec can do better than 20ms in the first place), given that there's probably much more data available to send at any given time?
- toast0 2y ago> Do video calls have lower latency audio (assuming the codec can do better than 20ms in the first place), given that there's probably much more data available to send at any given time? At least for WebRTC, no. The audio and video streams are separate, there's no mechanism in WebRTC to piggyback audio onto video packets. If the receiver is synchronizing audio with video, there's potential for additional delay (but when A/V sync works, it's probably worth it) I don't know details about WhatsApp calling (although I worked there, I didn't touch the realtime calling stack), I think it does use RTP which isn't really built around piggybacking, but since it's a closed service, they can do whatever. No idea about Apple's calling either.