3 ms·

There is several standards in the professional space, Dante being the biggest for "audio over ethernet". It's packet switched, so buffering is required. AES50

There is several standards in the professional space, Dante being the biggest for "audio over ethernet". It's packet switched, so buffering is required. AES50 works over cat5 cables, but doesn't use ethernet; it uses a synchronous clock to transmit PCM audio. A lot of the Midas/X32 product lineup uses this to great effect. Dante allows normal IP equipment to function as audio distribution devices, but has noticeable latency for close-quarters stuff (sound travels ~ .9ms / foot +-10%). AES50 has extraordinarily low latency, pretty much as good as analog, but only allows point-to-point links. On the consumer side, RAOP existed for awhile before silicon valley elitism infected Apple: https://en.wikipedia.org/wiki/Remote_Audio_Output_Protocol https://en.wikipedia.org/wiki/Remote_Audio_Output_Protocol EDIT ==== I had in my head the RAOP was an open standard, it's not.

nickysielicki 5y ago
Dante now has an OCI runtime that can do this purely in software without an ultimo, ala Dante Virtual Soundcard on the Windows side, which is a good example of how the embedded space is adapting to this prolonged part shortage. https://www.audinate.com/products/manufacturer-products/dante-embedded-platform https://www.audinate.com/products/manufacturer-products/dant...
xxpor 5y ago
Regular ethernet can do much better than .9 ms / ft, but it would indeed require some buffer size tuning to a level most consumer routers/switches wouldn't allow. Or even better: https://en.wikipedia.org/wiki/Cut-through_switching https://en.wikipedia.org/wiki/Cut-through_switching
- exabrial 5y ago
  The real problem with Dante is the buffering required, the wire speed is more than sufficient. Ethernet Packets are "best effort", making latency less predictable. Let's say your original source could be heard by the audience. The audio can travel from source, to mic, be digitized, transmitted over IP, arrive at console, be digitally mixed, then transmitted over IP to speaker, then broadcast at an unknown distance from the source. How much latency occurred there? The trick is to get the original source wave to roughly line up with the time the amplified wave leaves the PA speaker, otherwise weird echos are heard by the audience at best, and awful band-specific noise cancellation happens at worse.
  - cormacrelf 5y ago
    It's designed for big studio buildings and stadiums. Surely they need latency correction anyway, so the design didn't need to fix it? And you'd think slapping timestamps on all the packets would make it pretty easy to calculate the latency.

nickysielicki 5y ago

Dante now has an OCI runtime that can do this purely in software without an ultimo, ala Dante Virtual Soundcard on the Windows side, which is a good example of how the embedded space is adapting to this prolonged part shortage. https://www.audinate.com/products/manufacturer-products/dante-embedded-platform https://www.audinate.com/products/manufacturer-products/dant...

xxpor 5y ago

Regular ethernet can do much better than .9 ms / ft, but it would indeed require some buffer size tuning to a level most consumer routers/switches wouldn't allow. Or even better: https://en.wikipedia.org/wiki/Cut-through_switching https://en.wikipedia.org/wiki/Cut-through_switching

exabrial 5y ago
The real problem with Dante is the buffering required, the wire speed is more than sufficient. Ethernet Packets are "best effort", making latency less predictable. Let's say your original source could be heard by the audience. The audio can travel from source, to mic, be digitized, transmitted over IP, arrive at console, be digitally mixed, then transmitted over IP to speaker, then broadcast at an unknown distance from the source. How much latency occurred there? The trick is to get the original source wave to roughly line up with the time the amplified wave leaves the PA speaker, otherwise weird echos are heard by the audience at best, and awful band-specific noise cancellation happens at worse.
- cormacrelf 5y ago
  It's designed for big studio buildings and stadiums. Surely they need latency correction anyway, so the design didn't need to fix it? And you'd think slapping timestamps on all the packets would make it pretty easy to calculate the latency.