The problem with milliseconds is that most people can’t relate to them, so everybody wants zero ms.
A pragmatic presentation is meters - 1ms = 0.343m and 3ms = 1m.
If two musicians are in the same city, but use different ISP(internet service providers) the signal will probably go hundreds of kilometers to the next ISP exchange point and back.
If they share the same ISP and are lucky, the signal will only go tens of kilometers to the city exchange point. In any case, the number of hops is normally more relevant to latency than the number of kilometers.
If we agree that a total end-to-end latency of 20ms is perfectly tolerable and above 50ms is highly problematic, this table gives us some estimate what European cities can play well together.
Transcontinental connections will usually be above 100ms and therefore need a different musical approach. Some exceptionally expensive technologies provide 45ms between EU and US, but that is out of scope for most musicians today.
Hi, just wondering about the latency value shown in the house of consorts.
How does this value correlate with a „ping“? I think a ping is both ways. Does it include the router and house-eth-connection to the real computer?
Again: a ping can be done easily without additional equipment to decide wether to be able to play with friends or not; this would base an invest on facts and not only on the wish to stay connected with friends… Am i right?
Ping is only a very short package of 32byte, one per second, and realtime audio + video is much more traffic and UDP instead of ICMP like ping or TCP as web traffic. Ping ignores buffer bloat that is a real nightmare for real-time audio. Ping might take different routes every so often, depending on Internet traffic. I still use it as easy best-case measurement, MTR has some improved parameters.
Add fast.com to the mix, since it uses actual real Netflix-payload, so it cannot easily be prioritized by ISPs since they hate Netflix and would rather slow it down than speed it up, as the do with Speedtest.net traffic.
Ping works internally travelling two-way, since there would not be a way to show result times if the packet would not return, but 15ms says 15ms end to end, one-way e2e path but Ethernet only, from socket to socket.
ov-box shows real end to end latency INCLUDING processing in box. You can see this in my measurements comparing actual sound-wave latency to ov-latency. fast.com also shows you loaded latency, what ping times you get if you create some serious traffic - it’s usually 3-5x ping latency.
To get a step closer to the performance of digital-stage.org, use the command
If you use digital-stage-pc or digital-stage-box in p2p mode, no router is involved. You must find out the ip address of your peer and ping her PC. We had ensembles in one city playing all under 7ms. We have also musicians from Berlin and Köln experiencing 7ms between them, so sometimes the ISP gods are gracious.
Very interesting data! In our experience though, low latency is only a required data point, not sufficient. The much more critical value is packet jitter, because the amount of jitter dictates either the amount of dropouts or more likely the size of jitter buffers you need to introduce, and they outweigh real network latency very quickly.
Also, package drops can be a concern depending on your forward error correction strategy (how much additional data to your send).
We found not surprisinly that fibre network here in Munich is very predictable with near no jitter, while the worst case we had was a Vodafone cable internet somewhere in Schleswig-Holstein, where buffering caused batches of packets to be delivered at very high speed, unfortunetely requiring jitter buffers > 20 ms.
Jitter is absolutely important, and more difficult to understand predict and to believe.
Most users just don’t believe us when we say Wi-Fi is no good, and cable Internet is so much worse than DSL is so much worse than FTTH.
For the geographic global transmission the jitter is much less important to understand than for the last mile. only when two propagation paths change very often you get additional bad jitter. In general, jitter is always on top, and you must never expect the ping time to be your experience.
I had 180ms loaded jitter vs 15ms unloaded jitter today, as measured with fast.com.
BTW, Currently we don’t use a lot of concealment or FEC but try to be as fast as possible.
Regarding the latency values in House of Consort: Those are a close approximation of the true latency from one microphone to the other headphones. It includes:
half of ping time (because ping is round-trip)
the length of jitter buffers
10ms as an approximation of the hardware delay
I measured the delays in several conditions using external measurements and found a very close match (order of 2 ms).
Ping measurement only poorly reflects true audio streaming latency, mostly because of Buffer Bloat. A good test and article to understand it and some remedies for LAN routers is Bufferbloat Test by Waveform