ISDN lines were favored by radio stations forever because of the reliably low latency and jitter they offered.
Actual numbers? I wanna guess ~100ms max for a cross country call, pre-digital long distance. Maybe 350ms post digital. IIRC the ISDN hop I had to a local CO was ludicrously low, like 9ms? but i could be wrong. That was years ago.
Digital links for internet connections were lower inherent latency but then had layers of other modulation happening on top of them, and the variations there are a different order of thing. I assume you mean bare link latency.
I've NFI how many different layers of re-encoding your data might be expected to go through on a standard call today; but the list of transitions would probably be long and amusing.
Digitial T1 PRI calling may not be fully dead, you might have a miniscule delay for the analog to digital sampling, but the multiplexing on a T1 and higher is one sample per channel at a time. Where trunks meet, there's got to be a buffer to synchronize, but it doesn't need to be more than one sample. At 8000Hz sampling, a couple one sample buffers here and there doesn't amount to much. Of course, there's still amplifiers and the speed of light in wires and radio.
For VOIP calls, most audio codecs deal in 20ms packets, and calling software often sends between 1 and 5 audio packets in an IP packet. Plus it takes time to encode and decode. So you've probably got 25 to 110ms sampling delay added there. Then there's a jitter buffer. T1 samples arrive on time, pretty much all the time; UDP packets tend to have inconsistent delay (jitter) so you've got to add an artificial delay of (worst case delay - best case delay). That depends a lot on the properties of the path between the two devices; shared medium networking like wifi, cell networks, cable modems, old unswitched ethernet can have a lot of difference between worst and best case delay. Some software has a fixed length jitter buffer of about 1-2x the IP packet length; others will adapt to the observed arrival time differences, up to some limit.
Some (I think most) video calling applications send audio and video as separate streams of IP packets. It's also possible to include audio and video data in the same IP packets. It is possible to reduce audio delay in that case, by using smaller audio packets, reducing the sampling delay. It's technically possible to send small audio packets at higher frequencies for an audio only call, but the overhead of an IP header, UDP (usually) header, and application header is already pretty significant. Sending twenty 1 ms audio packets would use a lot more bandwidth than sending one 20 ms audio packet; I'd guess about 10 times as much. But if you piggyback on video packets, it might not be as costly, and video packets are usually high frequency anyway.
> Circuit switched analog POTS has been dead for a long time, but delays were limited to amplifier delays (almost nothing) and speed of light in wires or radio.
Two questions about this: it sounds like there are still a fair amount of landlines around if this article is accurate: https://www.cnn.com/2024/02/05/tech/landline-phone-service-p... Do you mean that people still have landlines, but they're no longer circuit switched analog? And would that only be for long distance, with local landline calls still using circuit switched analog, or would it be for both?
Also, as to your latter point about old school POTS having almost no delays other than speed of light: does that hold for long distance calls as well? I get the impression that there could be added latency for long distance POTS calls (but have had trouble finding sourced numbers on anything yet).
Long distance (to most destinations) calling probably switched to digital trunks faster than local calling, because long distance calling was already separate equipment from local calling, and replacing central office switches is a big process (including a pretty intense cutover [1]).
Long distance calling would have more equipment in the path than a local call, of course, and may not have had very optimal routing paths compared to today. I found a route map from the 1960 AT&T Long Lines network [2], and a fiber map with no provenance of 'today' [3] ... it's widely similar, but there's some routes that pop out at me as not being well connected in the 1960: Salt Lake City to Seattle; Amarillo, TX to Dallas, TX. On the other hand, Long Lines was radio, and radio is faster than fiber, so that makes up a little.
There may have also been more cases where routing was simplified to be more manageable at the expense of delay... AT&T wouldn't have run long distance trunks from everywhere to everywhere, you might need to do hierarchical routing --- if you're on the east coast, route to New York, and from there to the big city near your destination, and then to destination, etc. There's still some of that in internet routing, but it's a lot less. BGP and internal routing protocols make it a lot easier to manage more direct connections and let the software figure things out.
But there's no need to add a large buffer for voice data for POTS, and it was very expensive to do it, so it wasn't done. There is a need to do it for VoIP, and it's no longer expensive, so it is done.
[1] https://www.youtube.com/watch?v=saRir95iIWk
[2] http://www.long-lines.net/places-routes/maps/MW6003.jpg from http://www.long-lines.net/places-routes/maps/MW6003.jpg
[3] https://i.insider.com/56e03df7918a0f7333e350f3?width=1190
[4] https://telephoneworld.org/telephone-switching-systems/step-...
