Live data from Hacker News

AES67 resources – Audio over IP protocol

hartung.io

31–35 of 35 posts

Re: AES67 resources – Audio over IP protocol

#31
post #7

This sounds like fun tech. But isn't this dead before it really lifts off? Intel 1588 is not supported by every customer-NIC, and far from supported by most switches and such. So if i have to build a "special" hardware environment anyway, why use AES67 and not some other proprietary solution without IP which may (? or may not) deliver better latency and jitter? Last time i checked (which is a while back), the same su…

There are economy of scale advantages to using standard protocols and hardware: the R&D is paid for by the computer industry, which is much larger than the audio industry. Many NICs have support for PTP hardware clocks and hardware time stamping, and (unlike AVB/TSN) AES67 will work with most network switches. It's also possible to implement software endpoints by pointing an RTP client at the AES67 peer (albeit, this won't be a true AES67 endpoint as it won't play out synchronously without a PTP synchronised media clock).

Re: AES67 resources – Audio over IP protocol

#32
post #12

Earlier quoted context omitted.

While this can't be dropped into a lot of existing networks, that doesn't really eliminate the advantages of IP. This might be best explained by analogy: VoIP. Various issues including security model, DHCP-based provisioning, and QoS mean that corporate VoIP phones are typically deployed on a specially prepared network using a dedicated VLAN. While various VoIP vendors claim that you can just drop their solution on y…

I get your point, and you may be right and it might take off. But is a latency of 2ms up to 50ms really attractive? I am in no way near audio engineering, but i can remember the MIDI-folks swearing about their 2ms latency.

AES67-2018 specifies packet times (latencies) of 125us, 250us, 333us, 1ms and 4ms. Senders and receivers may support additional packet times.

Re: AES67 resources – Audio over IP protocol

#33
post #8
post #7

This sounds like fun tech. But isn't this dead before it really lifts off? Intel 1588 is not supported by every customer-NIC, and far from supported by most switches and such. So if i have to build a "special" hardware environment anyway, why use AES67 and not some other proprietary solution without IP which may (? or may not) deliver better latency and jitter? Last time i checked (which is a while back), the same su…

I had a look at 1588 and was a rabbit hole of paywalls - latest draft seems to be https://standards.ieee.org/standard/1588-2019.html Why is a standards group paywalled!

You can also read the linuxptp code, it's beautifully written.

Re: AES67 resources – Audio over IP protocol

#34
post #8
post #7

This sounds like fun tech. But isn't this dead before it really lifts off? Intel 1588 is not supported by every customer-NIC, and far from supported by most switches and such. So if i have to build a "special" hardware environment anyway, why use AES67 and not some other proprietary solution without IP which may (? or may not) deliver better latency and jitter? Last time i checked (which is a while back), the same su…

I had a look at 1588 and was a rabbit hole of paywalls - latest draft seems to be https://standards.ieee.org/standard/1588-2019.html Why is a standards group paywalled!

Yes almost anything to do with Industrial Ethernet type standards are all over the place. 1588 PTP mixes with IETF TICTOC workgroup output. Synchronous data also gets used in Psuedowire backhaul for low level circuit emulation signaling like from SCADA or GSM towers etc. And that's without going into IECxxxxx's for powerplant comms.

Certifiable Precision Timeing over anything is not trivial.

Post reply on HN